Medication administration and management system and method

ABSTRACT

A system, method and computer program for programming a medical device to administer a medication to a patient includes the medical device, a scanner that may be associated with a point of care (POC) system, and a medication management unit (MMU). A computer in the POC system can directly program the medical device with the permission of the MMU after a full “five rights” check or the “right patient” check can be delayed until after the pump program is downloaded. Other workflows are disclosed for programming the medical device in manual, semi-automatic and automatic modes, with safety checks incorporated at various points.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the priority of U.S. Provisional PatentApplication No. 60/786,599, filed Mar. 28, 2006, which is incorporatedby reference herein in its entirety.

BACKGROUND OF THE INVENTION

The present invention relates to the field of delivering medication topatients, more particularly to an integrated system for maximizingpatient safety and caregiver productivity for medication delivery.

Modern medical care often involves the use of medical pump devices todeliver fluids and/or fluid medicine to patients. Medical pumps permitthe controlled delivery of fluids to a patient, and such pumps havelargely replaced gravity flow systems, primarily due to the pump's muchgreater accuracy in delivery rates and dosages, and due to thepossibility for flexible yet controlled delivery schedules. However,modern medical devices, including medical pumps, can be complicated andtime-consuming for caregivers to program. Medical facilities struggle toprovide appropriate caregiver staffing levels and training while holdingdown the cost of medical care. Human errors in pump programming andother medication errors can have adverse or even deadly consequences forthe patient. Medication errors, which are sometimes referred to asadverse drug events (ADE), can increase the length of hospital stay andthe cost of medical care for the patients involved or their healthcareinsurance carrier.

Therefore, a principal objective of this invention is to provide anintegrated medication management system that is flexible, reduces therisks of medication error, improves patient safety, and improvescaregiver productivity.

These and other objectives will be apparent to those skilled in the art.

A SUMMARY OF THE INVENTION

A system, method and computer program product for administering amedication to a patient with a medical device includes a point of care(POC) system and a medication management unit (MMU) in communicationwith each other. A computer in the POC system can directly program themedical device with the assistance or permission of the MMU after a full“five rights” check using an input device for receiving identificationinformation. A full five rights check ensures that the right medicationin the right dose or rate through the right device channel or route atthe right time is administered to the right patient. Alternatively, a“right patient” check can be delayed until after the pump program hasbeen downloaded to the pump by the POC system or the MMU.

The present invention is directed to a medication management systemwhich includes various computers, including a medication management unit(MMU) associated with a medical device for performing a medicationorder. The medication management system is flexible and integrated toprovide for enhanced patient safety and caregiver productivity with avariety of hospital information and point of care systems. Themedication management system can take various forms and provides methodsfor administering the right medication in the right dose or rate throughthe right device channel or route at the right time to the rightpatient. By confirming the accuracy of the drug, dose, patient, time,and route, medication errors at the bedside can be prevented before anADE occurs. The caregiver confirms and starts the infusion of themedication order at the pump only if these bits of identificationinformation match the order.

The MMU is able to determine the network IP address of a medical deviceit is in wireless communication with based on the factory-established orhospital-established logical address of the medical device. The MMUmonitors the general physical location of a medical device based on thelast access node used by the wireless connectivity capability in themedical device.

The device is capable of storing two, simultaneous versions of a druglibrary—one in primary memory and another in cache memory. Uponoccurrence of a triggering event, the device will receive an updateddrug library, store it in its cache, and ultimately replace the existingdrug library in primary memory with the new library in the cache. Duringexecution of a medication order, the medical device utilizes the druglibrary in its primary memory.

In other embodiments of the medication management system of thisinvention, the MMU receives medication order and delivery informationfrom an information system directly through an electronic network orindirectly through a wireless handheld point of care (POC) input(scanning) device, such as a personal digital assistant (PDA). The PDAtransmits the delivery information and the medication order in the formof an infusion delivery order that may include various pieces ofinformation including but not limited to an infusion rate to the MMU.

The MMU translates the simple infusion rate of the delivery order intodelivery programming code or information suitable for automaticallyprogramming the designated pump and further checks the delivery orderand delivery programming code against a variety of drug libraryparameters (including but not limited to hard and/or soft limits fordrug delivery rates, dose, volume, duration, route and site ofadministration), patient-specific safety factors, and clinical decisionsupport rules including drug compatibility and drug-drug interactions.The MMU can be configured by the user at the MMU console or clientworkstation to monitor the status of the pump and the infusion(including alarms, event logs, and pump user interface inputs), generatereports, and control the distribution of drug library and operatingsoftware code updates to one or more pumps. A drug library editor (DLE)deployed as a part of the MMU, its console, or on a separate computer(DLE client workstation), enables the user to import, export and editwhole drug libraries and individual drug library values to control andcustomize a drug library according to hospital preferences.

The MMU and/or the POC system saves the caregiver time by automaticallypopulating or programming data entry fields in the pump that previouslyhad to be entered manually. The medication management system of thisinvention enhances patient safety by minimizing manual entries. Thesystem also enhances patient safety by screening drug delivery ordersfor conformance with established hospital practices, expert or clinicaldecision support rules and recommendations before, or more preferablyimmediately before, the pump begins to execute the order. The caregiveris provided with a least one and preferably several opportunities tocatch a medication error before it happens. The caregiver can confirmthe order at the point of care (POC) system and/or before starting theinfusion at the pump. The system is flexible enough to permit humaninterventions and overrides, and tracks such events for documentation,reporting, benchmarking and trouble-shooting purposes.

In one embodiment, a method is provided for administering a medicationto a patient with a medical device. The medical device can be aninfusion pump, and the medication can be a medication solution forinfusion into the patient. The method receives at a first computer, incommunication with a second computer, caregiver specific identificationinformation, drug container specific identification information, medicaldevice specific identification information, with one or moreidentification receivers or input devices, such as a handheld wirelesspersonal digital assistant (PDA) having barcode scanner for scanningbarcoded information. The drug container specific identificationinformation is located on a container containing the medication. Thefirst computer can be computer in a POC system and the second computercan be a medication management computer, such as the MMU mentioned aboveand further described below. The caregiver specific identificationinformation can include the identification of a specific caregiver(i.e., name, social security number, ID number, and/or some otheridentifier), or provide “look-up” information for retrieving theidentification of a specific caregiver. The medical device specificidentification information can include the identification of a specificmedical device (i.e., a logical name or address, the IP address, or someother information identifying an infusion pump), or provide “look-up”information for retrieving the identification of a specific medicaldevice. Likewise, patient specific identification information caninclude the identification of a specific patient (i.e., name, socialsecurity number, ID number, digital photograph and/or some otheridentifier) or provide “look-up” information for retrieving theidentification of a specific patient. In addition, the medical devicespecific delivery information can be actual data required to operate themedical device or the general medical order information specific to thetype of medical device (i.e., for an infusion pump, which could includestart time for an infusion, rate of an infusion, and volume to infuse).

The method also retrieves at the first computer medical device specificdelivery information based on the drug container specific identificationinformation, transmits to the second computer from the first computerthe medical device specific identification information and the medicaldevice specific delivery information, and transmits the medical devicespecific delivery information from the second computer to the medicaldevice. The medical device can have a medical device memory for storingthe medical device specific delivery information for use in programmingthe medical device to deliver the medication to the patient. After atleast one of the aforesaid transmitting steps, the method receives atthe first computer patient specific identification information, andcompares at least one of the received drug container specificidentification information and the patient specific identificationinformation to stored medication order information within a first memoryassociated with the first computer. The method further transmits a firstmedication delivery initiation signal to the second computer if thereceived drug container specific identification information and/or thepatient specific identification information matches the storedmedication order information within the first memory associated with thefirst computer, and, at least in part in response to receiving the firstmedication delivery initiation signal at the second computer, the secondcomputer transmits a second medication delivery initiation signal to themedical device to initiate the delivery of the medication to the patientusing the medical device specific delivery information previouslyreceived by the medical device.

In another embodiment, the first memory associated with the firstcomputer further comprises a plurality of medical administration records(MARs), wherein at least one MAR comprises a medication order.

In another embodiment, the above comparing step is performed withoutusing the patient specific identification information.

In another embodiment, the drug container specific identificationinformation comprises at least one of patient identificationinformation, medication identification information, universalidentification information, medication order information, and/or medicaldevice delivery information.

In another embodiment, the method receives at the first computer patientspecific identification information from the input device prior totransmitting to the second computer from the first computer the medicaldevice specific identification information and the medical devicespecific delivery information, and/or prior to transmitting the medicaldevice specific delivery information from the second computer to themedical device.

In another embodiment, the method transmits the patient specificidentification information from the first computer to the secondcomputer prior to the above comparison step.

In another embodiment, the method transmits the patient specificidentification information from the second computer to the medicaldevice prior to the comparison step.

In another embodiment, the method receives from the second computer, incommunication with the medical device, an availability state signal forthe medical device, and, if the availability state signal for themedical device indicates that the medical device is available, then themethod transmits the medical device specific delivery information to themedical device for programming the medical device to deliver themedication to the patient. The method can further compare at least oneof the received drug container specific identification information andthe patient specific identification information to stored medicationorder information stored within a first memory associated with the firstcomputer, and transmit a first medication delivery initiation signal tothe medical device if the received drug container specificidentification information and/or the patient specific identificationinformation matches the stored medication order information within thefirst memory. In one embodiment, these comparing and transmitting stepsare only performed if the availability state signal for the medicaldevice indicates that the medical device is available. In anotherembodiment, the method only transmits the medical device specificdelivery information to the medical device if the received drugcontainer specific identification information and/or the patientspecific identification information matches the stored medication orderinformation within the first memory. In a further embodiment, if theavailability state signal for the medical device indicates that themedical device is not available, then the method prevents anytransmission of the medical device specific delivery information to themedical device.

In another embodiment, the method generates at the second computer firstkey information and second key information, transmits from the secondcomputer the first key information to the first computer, transmits fromthe second computer the second key information to the medical device,transmits from the first computer the first key information to themedical device along with the medical device specific deliveryinformation, and compares at the medical device the first keyinformation to the second key information. In one embodiment, if a matchexists between the first key information and the second key information,then the method displays the medical device specific deliveryinformation on a display of the medical device for review by a caregiverto confirm that at least the medical device specific deliveryinformation is correct for the patient. In another embodiment, if amatch exists between the first key information and the second keyinformation, then the method operates the medical device according tothe medical device specific delivery information. The first keyinformation and/or the second key information can be an encryptedsecurity token. The method can further transmit from second computer tothe first computer the IP address of the medical device, if theavailability state signal for the medical device indicates that themedical device is available. In one embodiment, the first computer andthe first memory associated with the first computer do not maintain theIP address of the medical device. Alternatively, the first memoryassociated with the first computer can store the IP address of themedical device within a MAR for the patient for tracking to whichmedical device the medical device specific delivery information istransmitted.

In another embodiment, the first key information includes a time stamp,and the method compares at the first computer the time stamp to a firstactual time. If the difference between the time stamp and the firstactual time is less than a predetermined time criteria, then the methodtransmits from the first computer the first key information to themedical device along with the medical device specific deliveryinformation to the medical device. The method can also transmit the timestamp to the medical device, and compare at the medical device the timestamp to an actual time. If the difference between the time stamp and asecond actual time is less than the predetermined time criteria, thenthe method programs the medical device with the medical device specificdelivery information.

In another embodiment, the second key information comprises a secondtime stamp, and the method compares at the medical device the first timestamp and the second time stamp to an actual time. If the differencebetween the first time stamp and the actual time, and if the differencebetween the second time stamp and the actual time, are both less than apredetermined time criteria, then the method programs the medical devicewith the medical device specific delivery information.

The present invention is also directed to a system for implementing theabove and other methods, as well as a computer program product foroperation within a medication management computer for implementing aleast a portion of the above and other methods, for administering amedication to a patient using a medical device.

Other features and advantages of the invention will be apparent from thefollowing specification taken in conjunction with the followingdrawings.

DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic diagram showing a system and method foradministering a medication to a patient using a point of care computersystem comprising a POC server and a thick client input device accordingto one embodiment of the present invention.

FIG. 2 is a schematic diagram showing a system and method foradministering a medication to a patient using a point of care computersystem comprising a POC server and a thin client input device accordingto one embodiment of the present invention.

FIG. 3 is a front view of a medical device with a display and userinterface, wherein the medical device is stopped and not displayingprogrammed infusion settings.

FIG. 4 is a front view of a medical device with a display and userinterface, wherein the medical device is displaying downloaded infusionsettings for confirmation or modification.

FIG. 5 is a simplified pictorial schematic diagram of a system foradministering medication to a patient according to one embodiment of theinvention.

FIG. 5A is a simplified pictorial schematic diagram of a system foradministering medication to a patient similar to FIG. 5 but shows thepatient with a RFID wristband for auto-associating the patient and themedical device into a patient area network according to one embodimentof the invention.

FIG. 6 is a screen shot of one embodiment of a delivery informationinput device for inputting identification information and/or confirmingdelivery programming code data.

FIG. 7A is a flow chart showing a method for administering a medicationto a patient according to one embodiment of the present invention.

FIG. 7B is a continuation of the flow chart of FIG. 7A.

FIG. 8A is a flow chart showing a method for administering a medicationto a patient according to one embodiment of the present invention.

FIG. 8B is a continuation of the flow chart of FIG. 8A.

FIG. 9A is a flow chart showing a method for administering a medicationto a patient according to one embodiment of the present invention.

FIG. 9B is a continuation of the flow chart of FIG. 9A.

FIG. 10A is a flow chart showing a method for administering a medicationto a patient according to one embodiment of the present invention.

FIG. 10B is a continuation of the flow chart of FIG. 10A.

FIG. 11A is a flow chart showing a method for administering a medicationto a patient according to another embodiment of the present invention.

FIG. 11B is a continuation of the flow chart of FIG. 11A.

FIG. 12 is a flow chart showing a method for administering a medicationto a patient according to another embodiment of the present invention.

FIG. 13 is a flow chart showing a method for administering a medicationto a patient according to another embodiment of the present invention.

FIG. 14 is a flow chart showing a method for administering a medicationto a patient according to another embodiment of the present invention.

FIG. 15 is a flow chart showing a method for administering a medicationto a patient according to another embodiment of the present invention.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS(S)

In the figures and the description that follows, like reference numeralsgenerally refer to like components or steps. In general, the systemcomponents described herein are described in greater detail in thecommonly owned published United States Patent Application 20050144043,the disclosure of which is incorporated herein by reference in itsentirety.

Definitions are provided below for some terms that appear in thisdescription.

“Medical device” includes without limitation a pump, a monitor formonitoring patient vital signs or other parameters, or a diagnosticdevice. Typically a medical device is located in a particular physicallocation or clinical care area (CCA) within a hospital or some otherenvironment. The medical device has a logical identifier or logicaladdress and, when in contact with a communication network, has a networkinternet protocol or IP address if it is on a communication network

“Pump” includes without limitation a device that acts upon a cassette,reservoir, vial, syringe, or tubing to convey medication or fluid to orfrom a patient (for example, without limitation, an enteral pump, aninfusion pump, a patient controlled analgesia (PCA) or pain managementmedication pump, or a suction pump.

“Medication” as used herein is something that has a physiological impacton a person or animal, including but not limited to liquid or gaseousfluids, drugs or medicines, liquid nutritional products and combinationsthereof. Medications that are delivered intravenously to patients aregenerally in liquid form, and are thus also referred to herein as“solutions”.

With reference to FIGS. 1 and 2, the medication management system (MMS)of the present invention includes a medication management unit (MMU)3108, 3208 and a medical device 3130, 3230, typically operating inconjunction with one or more information systems or components of ahospital environment as further discussed below.

IV fluids/medications 3100, 3200 in containers 3102, 3202 can beadministered to a patient 3104, 3204 through the system(s) shown inthese FIGS. While the embodiments shown in FIGS. 1 and 2 utilizebarcodes and a barcode reader as means for providing and inputting orreading machine readable information for identification or otherpurposes, those skilled in the art will appreciate from this descriptionthat other means for providing and reading information can be utilized.Machine readable indicia or identifying information can be provided by aradio frequency identification (RFID) tag, transmitter, or transponderand read by a radio frequency receiver or transceiver. Digitalphotography or imaging and scanning technology can be used. Humanbiometric data, including but not limited to skin/fingerprints, retinapatterns, voice, etc can be recognized by an appropriate scanner orreceiver. An input device 32 or identification receiver adapted to“read” or recognize such indicia can be provided.

The IV fluids/medications 3100, 3200 in barcode-identified containers3102, 3202 can be given new or supplemental label(s) with a uniqueinfusion order identifying barcode by the pharmacist according tohospital practice. In particular, the drug container specificidentification information, such as barcoded information on thecontainer 3102, 3202, can include patient identification information,such a patient name, patient number, or medical record number for whichthe medication has been prescribed, medication identificationinformation, such as a medication name of the medication or solutionwithin the IV bag or container 3102, 3202, universal identificationinformation which can be created or assigned at the hospital, medicaldevice delivery information, such as the operating parameters to use inprogramming an infusion pump to deliver the medication 3100, 3200 to thepatient 3104, 3204, and/or medication order information, such as one ormore of the above information items and/or other medication orderinformation specific to a particular patient 3104, 3204, and which maybe a part of a medication order for a particular patient. The IVfluids/medications 3100, 3200 in barcode-identified containers 3102,3202 can be supplied to hospitals by various vendors, with preexistingunique barcode identifiers which include medication information andother information, such as National Disease Center (NDC) code,expiration information, drug interaction information, and otherinformation.

The universal identification information on the container 3102, 3202 canbe a unique medication order identifier that, all by itself, identifiesthe order associated with the container. Alternatively, theidentification information on the container 3102, 3202 can be acomposite patient/order code that contains both a patient ID (usually amedical record number) and an order ID (where the order ID is uniqueonly within the context of that patient). Alternatively, theidentification information on the container 3102, 3202 is merely amedication ID. Within a given hospital, all medications prepared orpackaged for patients by the pharmacy will contain either a universallyunique order ID or a composite patient/order ID, but generally not bothwithin the same institution. The medication ID alone option is typicallyused only for medications that are pulled by the nurse directly fromfloor stock at the point of care.

The systems identified in FIGS. 1 and 2 can have a “drug library editor”or DLE computer 3106, 3206 such as a desktop, notebook, or servercomputer, with DLE software that runs on the DLE terminal, computer orworkstation 3106, 3206 also shown as “DLE Client” in FIGS. 1 and 2. Asdescribed above, a medication management unit (MMU) or computer 3108,3208, such as a server, has MMU software that is installed and runs onthe MMU server 3108, 3208. The drug library and other databases can bestored on the MMU server 3108, 3208, a separate server, and/or in remotelocations.

Hospital information systems (HIS) 3110, 3210 typically include one ormore computers hard-wired together into a network 76 (FIGS. 5 and 5A) bycabling, interfaces and/or Ethernet connections. Alternatively wirelessconnections and communications can be used in whole or in part. Serversprovide processing capability and memory for storage of data and variousapplication programs or modules, including but not limited to a modulefor admissions-discharge-and-transfer (ADT) 3112, 3212, a computerizedphysician order entry (CPOE) module 3114, 3214, and a pharmacyinformation system (PhIS or PIS) module 3116, 3216. Hospital personnel,such as admission clerks 3118, 3218, physicians 3120, 3220, andpharmacists 3122, 3222, respectively, can be authorized to access thesemodules through client workstations connected to the servers in order toenter data, access information, run reports and complete other tasks.

In the embodiment shown in FIG. 1, the HIS 3110 can also include a pointof care (POC) system 3125 including a server or POC computer 3124(sometimes referred to as a barcode point of care server or computer),or the POC computer 3124 can be separate from the HIS 3110. In eithercase, the POC computer 3124 is typically hard-wired into the HISnetwork. The POC computer 3124 acts as part of a point of care (POC)system 3125 (sometimes referred to as the barcode point of care systemor BPOC) and is able to wirelessly communicate through a plurality ofwireless communication nodes located throughout the hospital, utilizinga wireless communications protocol, such as IEEE 801.11, IEEE 802.11, orBluetooth. A wireless communication node 84 with an antenna 82 istypically included in each patient room or treatment area, as shown inFIG. 5. In the embodiment shown in FIG. 1, the POC computer 3124wirelessly communicates with a portable “thick client” POC or inputdevice 3126 carried by the caregiver. Referring to FIGS. 5 and 5A, thePOC client device 3126 can be a personal digital assistant (PDA) that isequipped with or connected to a barcode scanner or other identificationreceiver/reader 32 such as a radio frequency (RF) receiver for receiving“RF tag” information when an RF tag is sufficiently near the RFreceiver. The POC client device 3126 is referred to as a “thick client”because it has significant memory, display and processing capabilitiesof its own and can execute a variety of programs stored in its memory insome degree independently of the POC computer 3124.

In one embodiment of FIGS. 1 and 2, the MMU server 3108, 3208 ishard-wired to the DLE client desktop computer/workstation 3106, 3206 andto a MMU client computer/workstation 3128, 3228. Alternatively, the MMUand DLE client functions can be combined onto a single clientcomputer/workstation or may reside together with the MMU server 3108,3208 on a single combined MMU/DLE server. The MMU server 3108, 3208preferably resides in a location remote from the patient's room ortreatment area. For instance, the MMU server 3108, 3208 can reside in asecure, climate controlled information technology room with otherhospital servers and computer equipment and its client terminals can belocated in the pharmacy, biomedical engineering area, nurse station, orward monitoring area. One MMU server 3108, 3208 can monitor, coordinateand communicate with many infusion pumps 3130, 3230. For example, in oneembodiment, the MMU software running on the MMU server 3108, 3208 cansupport up to one thousand infusion pumps concurrently. In the thickclient embodiment shown in FIG. 1, the MMU server 3108 need not beconnected (hard-wired or wirelessly) to the hospital's Ethernet networkbackbone.

In the thick client embodiment of FIG. 1, the thick client PDA 3126 inthe POC computer system 3125 may communicate in a peer-to-peer mannerwith the MMU server 3108. The MMU server 3108 interfaces or communicateswirelessly with the infusion pump 3130 and the PDA or POC client 3126through the same wireless nodes 84 utilized by the POC system 3125 and aconnectivity engine and antenna 78 (FIG. 5) on or in the infusion pump3130. Communication between the MMU server 3108 and the POC system 3125takes place through the PDA (POC client 3126)/MMU server 3108 wirelessinterface. Communication between the infusion pump 3130 and the POCclient 3126 takes place through the MMU server 3108. Each thick POCclient 3126 stores in an associated memory the URL address or internetprotocol (IP) address of each MMU computer 3108 and each POC client 3126communicates directly with such MMU computer 3108. The MMU computer 3108stores in an associated memory both the logical ID and the network ID orInternet Protocol (IP) address of the infusion pump(s) 3130, such thatonly the MMU computer 3108 can communicate in a direct wireless mannerwith the infusion pump 3130. Alternatively, as will be described later,the MMU 3108 can provide the IP address and other information about thepump 3130 to the POC system 3125 to facilitate direct communicationbetween the POC system 3125 and the pump 3130.

Regardless of whether the hospital uses the system architecture of FIG.1 or FIG. 2, certain activities related to patient care typically takeplace in a hospital environment. Upon admission to the hospital, theadmission clerk 3118, 3218 or similar personnel enters demographicinformation about each patient 3104, 3204 into an associated memory ofthe ADT computer or module 3112, 3212 of an HIS database stored in anassociated memory of the HIS system 3110, 3210. Each patient 3104, 3204is issued a patient identification wristband, bracelet or tag 112, 112A(FIGS. 5 and 5A) that includes an identifier 3103, 3203, such as abarcode or RFID tag for example, representing a unique set ofcharacters, typically a patient ID or medical record number, identifyingthe patient, sometimes referred to as patient specific identificationinformation. The wristband, bracelet or tag 112, 112A may also includeother information, in machine readable or human-readable form, such asthe name of the patient's doctor, blood type, allergies, etc. as part ofthe patient specific identification information.

The patient's doctor 3120, 3220 prescribes medical treatment by enteringan order into the CPOE computer terminal or module 3120, 3220 within theHIS system 3110, 3210. The order, as prescribed, may specify a starttime, stop time, a range of allowable doses, physiological targets,route, and site of administration. In the case of an order for infusionof fluids or medication, the order may be written in various formats,but typically includes the patient's name, patient ID number, a uniquemedication order or prescription number, a medication name, medicationconcentration, a dose or dosage, frequency, and a time of desireddelivery. This information is entered into the memory of the CPOEcomputer 3124, 3224, and is stored in a memory associated with at leastthe POC server or computer 3124, 3224.

The medication order is also delivered electronically to the PIScomputer 3116, 3216 in the pharmacy and is stored in an associatedmemory. The pharmacist 3122, 3222 screens the prescribed order,translates it into an order for dispensing medication, and prepares themedication or fluids with the proper additives and/or necessarydiluents. As best seen in FIGS. 1, 2, 5 and 5A, the pharmacist 3122,3222 prepares and affixes a label 102, 108 with drug container specificidentifying information 3101, 3201 to the medication or drug container3102, 3202. In one embodiment, the label only includes inmachine-readable (barcode, RFID, etc.) form a unique sequentiallyassigned “dispense ID number” that can be tied or associated to theparticular patient ID number and medication order number in the HIS3110, 3210, PIS 3116, 3216 and/or POC computer 3125, 3225.

In another embodiment, the label can include in machine readable form acomposite identifier that includes an order ID and a patient ID, whichis usually a medical record number. In another embodiment, the labeldoes not include a patient ID at all in barcode or machine readableformat but includes in machine readable form only a medication ID. Thislast embodiment may be useful for “floor stock” items that are commonlystocked in operating rooms, emergency rooms, or on a ward foradministration on short notice with ad hoc or post hoc orders. Inanother embodiment, the label may include in machine readable and/orhuman-readable form medical device specific delivery informationincluding but not limited to the dispense ID number, patient ID, drugname, drug concentration, container volume, VTBI, rate or duration, etc.Only two of the three variables VTBI, rate and duration must be definedas the third can be calculated when the other two are known. The labeledmedication typically is delivered to a secure, designated staginglocation or mobile drug cart on the ward or floor near the patient'sroom or treatment area. The medication order pending dispensing oradministration is posted to a task list in the HIS system 3110, 3210 andPOC system 3125, 3225 and stored in an associated memory.

The nurse 3132, 3232 uses the input device 32 or identificationreceiver/reader associated with the POC client 3126, 3226 to scan thecaregiver specific identification information 3133, 3233 or barcode onhis/her caregiver identification badge 116 and enters a password, whichlogs the caregiver into the system and authorizes them to access anurse's task list from the POC system 3125, 3225 through the POC client3126, 3226. The information within the nurse's badge is sometimesreferred to as the caregiver specific identification information herein.The nurse 3132, 3232 can see from the task list that IV drugs are to beadministered to certain patients 3104, 3204 in certain rooms. The nurse3132, 3232 obtains the necessary supplies, including medications, fromthe pharmacy and/or a staging area in the vicinity of the patient'sroom.

The following will be described with reference to FIG. 1, but may alsobe applicable to the embodiment of FIG. 2. The nurse 3132 takes thesupplies to a patient's bedside, turns on the infusion pump 3130,verifies that the network connection icon on the pump 3130 indicates anetwork connection is present, selects the appropriate clinical carearea (CCA) on the pump, and may mount the IV bag, container, or vial3102 and any associated tube set as required in position relative to thepatient 3104 and infusion pump 3130 for infusion. Using theidentification receiver/reader 32 integral to the POC client PDA 3126,the nurse 3132 scans the barcode on the patient's identificationbracelet 112. A task list associated with that particular patient willappear on the PDA 3126 screen. Presumably this task list, which may alsoinclude orders to give other forms of treatment or medication by otherroutes (oral, topical, etc.), is obtained from the HIS via the POCserver 3124 and communicated wirelessly to the POC client PDA 3126. Inone embodiment, the list is generated by matching the scanned patient IDwith the patient ID for orders in memory within the POC server 3124. Inanother embodiment, as will be described below, the order informationcan be obtained by scanning the drug container specific identificationinformation, for associated orders in memory within the POC server 3124,through the following step(s).

The nurse 3132 scans the medication barcode label 102 containingmedication container specific identification information 3101 on themedication container 3102 with the PDA 3126. The PDA 3126 highlights theIV administration task on the task list and sends the scanned medicationcontainer specific identification information, such as dispense IDinformation, from the medication container 3102, to the POC server 3124,which uses the medication container specific identification information,such as the dispense ID, to pull together the rest of the order detailsand send them back to the PDA 3126. The PDA 3126 then displays an IVDocumentation Form on its screen, as illustrated for example in FIG. 6.One side of the IV Documentation Form screen shows the order details as“ordered” and the other side is reserved for a status report from theinfusion pump 3130. The status report from the infusion pump 3130 istransmitted to the PDA 3126 through the MMU server 3108, as will bedescribed below. The lower portion of the IV Documentation Form screengives the caregiver 3132 instructions (like to scan the infusion pump3130 barcode) or tells whether the pump is running or stopped.

The nurse 3132 then scans the barcode label 92, 96 (FIGS. 5 and 5A)associated with the infusion pump 3130 (or pump channel if the pump is amulti-channel pump). The barcode label 92, 96 contains medical devicespecific identification information 3131, such as the logical nameand/or logical address of the device or channel. The PDA 3126 thenautomatically bundles the information into a program pump requestcontaining the “order details” and in one embodiment, without furtherinteraction with the caregiver 3132, transmits this informationwirelessly to the MMU server 3108. In another embodiment the POC server3124 can transmit the order details to the MMU server 3108 via ahard-wired network connection.

The program pump request can includes the following information (inHIS/POC system format): a Transaction ID, which can include a LogicalPump ID, a Pump Compartment, a Pump Channel ID, a Reference DeviceAddress, a Caregiver ID, a Caregiver Name, a Patient/Person ID (HISidentifier), a Patient Name, a Patient Birth Date & Time, a PatientGender, a Patient Weight, a Patient Height, and an Encounter ID whichcan include a Room, a Bed, and a Building (including Clinical Care Areaor CCA). The program pump request can also include Order Information or“order details”, including an Order ID, a Start Date/Time, a StopDate/Time, a Route of Administration, a Rate, a Duration of Infusion(Infuse Over), a Total Volume to be Infused (VTBI), an Ad Hoc OrderIndicator, and Ingredients including HIS Drug Name or HIS Generic DrugName, HIS Drug Identifier or HIS Generic Drug ID, Rx Type (Additive orBase), Strength w/units, and Volume w/units. The program pump requestcan further include Patient Controlled Analgesia (PCA) Orders Onlyinformation, such a PCA Mode-PCA only, Continuous only, or PCA andContinuous, a Lockout Interval (in minutes), a PCA Continuous Rate, aPCA Dose, a Loading Dose, a Dose Limit, a Dose Limit Time w/units, aTotal Volume in vial, and Order Comments.

Upon receipt of a program pump request from the PDA 3126, the MMU 3108validates the request by making sure that all infuser-requiredinformation has been provided and that any information provided, whetherrequired or optional, is complete, within expected ranges and correctlyformatted. For example, if height is included but is not a valid numberor does not include units, the order would not be valid or complete. Ifthe validation is successful, the MMU 3108 responds to the PDA 3126 witha program pump reply message. If the validation is unsuccessful, the MMU3108 notifies the PDA 3126 via a program pump reply message and does nottransform or send the order to the infusion pump 3130. Likewise, if theinfusion pump 3130 is currently infusing, the MMU 3108 will reject therequest and indicate with an error description in the program pump replythat the infusion pump 3130 is not ready to receive an order. The nurse3132 must take some action to address the issue related to the infusionpump 3130, such as stopping the pump, retrying, or perhaps rescanningthe correct pump channel on the infusion pump 3130 if the wrong channelwas initially scanned. If the program pump reply message wasaffirmative, the PDA 3126 will repeatedly poll the MMU 3108 at regularintervals, for example every two seconds, with a read pump statusrequest until the MMU 3108 is able to respond with a pump status replybased on a status message the MMU 3108 receives from the infusion pump3130. The PDA 3126 also polls periodically for status updates as theinfusion progresses.

The MMU 3108 identifies what type of infusion pump 3130 (standard orPCA) the program pump request is targeting, and then transforms theorder into infuser specific details or settings. The MMU 3108 convertsor reformats numbers received from the HIS system 3110 to the particularsyntax, such as fixed-decimal point format for example, required by theinfusion pump 3130. Rounding, conversion, or mapping of certain data maybe needed to convert the information received from the PDA 3126 tosettings the infusion pump 3130 can recognize, accept and utilize. Anydata that is not required from the above listing can be left out of therequest, then the MMU 3108 will transmit the incomplete order to theinfusion pump 3130 and the caregiver 3132 can complete or modify theorder at the infusion pump 3130, if desired.

The MMU 3108 maps or converts the wide range of expressions of unitsallowed by the HIS system 3110 or POC system 3125 for PDA 3126 requestsinto the much more limited set of units allowed in the MMU 3108 andinfusion pump 3130. For example, the PDA 3126 request may express “g,gm, gram, or grams” whereas the MMU 3108 and/or infusion pump 3130 canaccept “grams” only. Infusion pump 3130 delivery parameters or infusionpump 3130 settings are mapped or converted from corresponding orderinformation or “order details” of the program pump request.

The MMU 3108 stores in an associated memory a mapping or translationtable that keeps track of the logical ID of an infusion pump 3130 andthe corresponding current network (static or dynamic) address (InternetProtocol (IP) address) or ID of the infusion pump 3130 on the network,which in this example is a wireless network. The MMU 3108 is able totranslate or associate a given logical ID of the infusion pump 3130 withits network address in the translation table and provide the network IPaddress to the requesting POC system 3125 or device. The MMU 3108 alsostores in an associated memory and/or can look up the drug libraryapplicable to the scanned infusion pump 3130 and also converts the DrugID and Strength from the pump program request into an index number ofthe medication at the desired strength or concentration from the druglibrary. The duration of the infusion comes from the POC system 3125 inhours and minutes and must be converted to just minutes for the infuserto recognize it. Volume or VTBI will be rounded to provide avalue-specific and infuser-specific number of digits to the right of thedecimal point. Units (of drug) will be converted to million units whereappropriate. Patient weight is converted and either rounded according toinfuser-specific rules or not sent to the infuser.

Once the MMU 3108 transforms the information from the program pumprequest into infusion pump settings or delivery parameters and otherinformation in a format acceptable to the infusion pump 3130, the MMU3108 wirelessly downloads a command message to the infusion pump 3130.If the infusion pump 3130 is not already equipped with the latestappropriate version of the hospital-established drug library, the MMU3108 can also automatically download a drug library to the infusion pump3130. The hospital-established drug library is maintained in a separateprocess undertaken by the biomedical engineer or pharmacist 3122 toplace limits on the programming of the infusion pump 3130, as well asother infusion pump operating parameters such as default alarm settingsfor air in the line, occlusion pressure, etc. The drug library sets upacceptable ranges or hard and/or soft limits for various drug deliveryparameters in the infusion pump 3130.

The MMU 3108 can also download to the infusion pump new versions,patches, or software updates of the infusion pump's internal operatingsystem software. The infusion settings or delivery parameters and otherinformation from the MMU 3108 is entered into the memory of the infusionpump 3130 and the infusion pump 3130 settings can automatically populatethe programming screen(s) of the infuser, just as if the caregiver 3132had entered the information and settings manually. The infusion pump3130 screen populates with the name of the drug and drug concentrationbased on the drug library index number, patient weight (if applicable),rate, VTBI, and duration (only two of the last three variable are sentby the MMU 3108 because the pump 3130 can calculate the third from theother two). A return message of confirmation signal is sent to the MMU3108 by the infusion pump 3130 to indicate that the command message hasbeen received. At this point the caregiver 3104 may manually enter anyadditional infusion settings or optional information that was notincluded in the command message.

The infusion pump 3130 then prompts the caregiver 3132 to start theinfusion pump 3130 by pressing the start button. When the caregiver 3132presses the start button, a confirmation screen with the infusionsettings programmed is presented to them for confirmation, as best seenin FIG. 4. When the caregiver 3132 presses the button to confirm, theinfusion pump 3130 will begin delivering fluid according to theprogrammed settings. The infusion pump 3130 sends a status message tothe MMU 3108 indicating that the infusion pump 3130 was successfullyauto-programmed, confirmed and started by the caregiver 3132, and is nowdelivering fluid. The MMU 3108 continues to receive logs and statusmessages wirelessly from the infusion pump 3130 periodically as theinfusion progresses or when alarms occur.

The MMU 3108 reports a portion of the initial status message to the PDA3126 (in MMU format) to indicate that the infusion pump 3130 has beenautoprogrammed and the caregiver 3132 has confirmed the settings. TheMMU 3108 communicates to the PDA 3126 the actual Rate, VTBI andDuration. As shown in FIG. 6, these values are filled into theappropriate actual (pump) fields on the opposite side of the PDA IVDocumentation Form screen from the corresponding “Ordered” values. Anotation at the bottom of the PDA screen indicates that the infusionpump 3130 is running. The PDA 3126 will compare and give a visual, audioor other type of affirmative signal if the pump information matches oracceptably corresponds with the ordered information. An initialdetermination of whether the pump information matches the order can bedone in the MMU 3108 and communicated to the PDA 3126. Alternatively,the POC server 3124 or the POC client PDA 3126 can make the necessarycomparisons. If the pump information does not match the order, the PDA3126 gives a visual, audio or other type of negative signal, which mayinclude an error message. The nurse can also be prompted by the POCclient or PDA 3126 at anytime during the process to enter the site ofadministration, and the PDA 3126 or the POC server 3124 matches thatinformation as well. The same notification scheme or signals, asdescribed above, can be followed for matching or mismatched conditionsrelating to the site of administration. In one embodiment, the site ofadministration is matched after the pump information is matched with theother order information.

The nurse 3132 is prompted to review and press a save button on the PDA3126 if the order has been begun as desired or any variations areacceptable. In a separate subsequent step, the nurse electronicallysigns the record and presses a send button to send the information tothe patient's electronic medication administration record (electronicMAR or EMAR).

Referring to FIG. 2, a thin client medication administration andmanagement system and method is shown. From an HIS perspective, thestructure is similar to the thick client POC structure described above,and shown in FIG. 1. However, the POC system 3225 includes POC server3224 and a thin client notebook, tablet, handheld or PDA computerworkstation 3226 that has little memory, computational power or abilityto run its own programs. Instead, the client workstation or input device3226 merely displays web pages it accesses from the server 3224 andrelays input information to the POC server or computer 3224. Theinformation is input through a user interface and/or an identificationreceiver/reader 32 integral with the POC client 3226 (FIG. 5) orconnected to the POC client 3226 by a USB cord as shown in FIG. 2.Although the POC client 3226 has wireless WI-FI capability, in oneembodiment, the POC client 3226 only communicates with the POC server3224. The thin POC client 3226 may be attached to a mobile drug cart,mounted on a wall, or mounted at the bedside in the patient's room. Thethin client computer 3226 at least temporarily stores data in a memoryassociated therewith in order to relay the data to the POC server 3224or to display the data.

The POC server 3224 is typically hard-wired for communication with theMMU server 3208, but wireless communication is also a possibility due tothe capabilities of the POC and MMU servers 3224, 3208.

The thin POC client 3226 of FIG. 2 is generally aninput/pass-through/display device. In this embodiment, the POC client3226 does not actually make any comparisons for five rights checking.The comparisons are made within the POC server 3224. The POC server3224, rather than the POC client 3226, communicates directly with theMMU 3208.

In operation, the nurse 3232 scans his/her ID badge 116 and enters apassword to access the system 3225 and an electronic MAR To-Do List thatis displayed on the POC client 3226 screen. The nurse 3232 gathers thenecessary supplies and medication, and then proceeds to the bedside ofthe patient 3204. The nurse 3232 places the IV bag 3202 or container andthe associated tube set in position with respect to patient 3204 and theinfusion pump 3230. The nurse 3232 turns on the infusion pump 3230,selects the clinical care area (CCA), and verifies that a wirelessconnection icon or indicator is present on the pump.

The nurse 3232 uses the identification (barcode) reader 32 on orattached to the POC client 3226 to scan the patient specificidentification information 3203 on the patient's wristband 112. Thewristband barcode includes a patient identification number inmachine-readable format, and/or other information described above. ThePOC client 3226 displays the various physician orders and medicationorders for the patient 3204.

The nurse 3232 scans the identifier, such as a barcode label 102 on themedication container or IV bag 3202 to obtain the medication specificidentification information 3201. The barcoded label 102 on themedication container 3202 includes the medication specificidentification information 3201, such as a unique number that is acombination of the patient ID and medication order number in a singleblock, as indicated above. The particular medication order associatedwith the medication container 3202 can retrieved from the medicationspecific identification information and/or from the POC server 3224, anddisplayed on the POC client 3226 screen along with an instruction forthe caregiver to scan the IV pump 3230 (or channel if the pump is amultiple channel pump). In one embodiment, the nurse 3232 scans thelabel 92 or 96 on the infusion pump 3230 or pump channel and hits the“next” button on the POC client 3226. The order details are thenretrieved from the POC server 3224 and displayed at the POC client 3226.

In one embodiment, nothing will happen until the nurse 3232 selects andenters the site (i.e., location on the body of the patient 3204) of theinfusion from a dropdown menu on the order details screen. Consistentwith the original order as prescribed by the physician 3220, thecaregiver 3232 can modify the order and/or supply additional informationsuch as rate, volume or other values which may be omitted in the orderfrom the pharmacy. For example, if the physician's order is written as“titrate to affect” until blood pressure is below 200/100, a particularrate may not have been supplied with the order as translated by thepharmacy. After checking the patient's blood pressure or reviewing thelatest measurements, the nurse 3232 may input a new or modified ratebased on the specific patient condition. Recent laboratory results orvalues may also be relied upon to determine or adjust the order withinthe prescription of the physician.

In response to the caregiver hitting “next” after entering the siteinformation and making any desired modifications to the orderinformation, the POC server 3224 will download the order information tothe MMU server 3208. A screen on the POC client 3226 indicates that thePOC server 3224 is “sending settings to the IV pump”, albeit through theMMU server 3208. The POC client 3226 screen instructs the nurse 3232 togo to the IV pump 3230 and confirm the settings on the display of thepump when they appear. The nurse 3232 also can change the settings byreprogramming the settings at the infusion pump 3230.

As in the “thick” client embodiment shown in FIG. 1, the MMU server 3208must transform the order information from format stored in the memoryassociated with the POC server 3224 into infusion pump-recognizablesettings. The MMU server 3208 also provides the latest appropriate druglibrary information for the infusion pump 3230 and converts the drugname and concentration information from the POC server 3224 into a druglibrary index number that the infusion pump 3230 understands. The MMUserver 3208 and infusion pump 3230 communication and workflow issubstantially the same as in the thick client embodiment. The nurse 3232reviews the infusion pump 3230 settings on the display 88 of theinfusion pump 3230, presses a start button, then is prompted with aconfirmation screen to confirms the settings again as shown in FIG. 4.The nurse 3232 presses “yes” at a confirmation screen to actually startthe infusion.

The infusion pump 3230 wirelessly communicates the start of the infusionand its infusion parameters back to the MMU 3208, which relaysinformation such as the dose, VTBI, duration, rate and backpressure(distal pressure) to the POC server 3224 for display on the POC client3226 display screen. Alternatively, the infusion settings or parameterscan be relayed back to the POC client 3226 through the MMU 3208 and POCserver 3224 at the press of the start button, and then updated when the“yes” button is pressed. The caregiver 3232 must hit “done” on the POCclient 3226 screen to send this information to the patient's EMAR.

With reference to FIGS. 1 and 2, another embodiment of the medicationadministration system and method will now be described. As mentioned,the POC client 3126 (FIG. 1) or the POC computer 3224 (FIG. 2) is incommunication with the MMU computer 3108, 3208. The POC server 3124,3224 is also in communication with the POC client input device 3126,3226. The nurse 3132, 3232 uses the POC client 3126, 3226 to scan his orher own badge 116, and the POC client 3126, 3226 processes and/or sendsthe caregiver specific identification information 3233 from the badge116 to the POC computer 3224 for receipt by the POC computer 3224. Thenurse 3132, 3232 uses the POC client 3126, 3226 to scan an identifier,such as a barcode label 102 for example, on the medication container3102, 3202 to obtain medication or drug container specificidentification information 3101, 3201 on the identifier, and the POCclient 3126, 3226 processes and/or sends the drug container specificidentification information to the POC computer 3124, 3224 for receipt bythe POC computer 3124, 3224. The nurse 3132, 3232 uses the POC client3226 to scan an identifier, such as a barcode label 92 for example, onthe infusion pump 3130, 3230 or a channel of the pump to obtain medicaldevice specific identification information 3131, 3231 on the identifier,and the POC client 3126, 3226 processes and/or sends the medical devicespecific identification information to the POC computer 3124, 3224 forreceipt by the POC computer 3124, 3224.

Using the drug container specific identification information, the POCcomputer 3124, 3224 finds or retrieves from its own memory or a memoryassociated with the POC computer 3124, 3224, the medication orderinformation associated with the drug container specific identificationinformation 3101, 3201, which contains medical device specific deliveryinformation for use in programming the infusion pump 3130, 3230. The POCcomputer 3224 or the POC client 3126 sends or transmits the medicaldevice specific identification information, such as the pump ID, thecaregiver specific identification information, such as the nurse's ID,the order ID obtained or retrieved from one of the drug containerspecific identification information or from the associated medicationorder stored in the memory associated with the POC computer 3224 and/orthe POC client 3126, and the medical device specific deliveryinformation, such as the pump settings for the order, to the MMUcomputer 3108, 3208.

In addition to or separate from other actions or functions which the MMUcomputer 3108, 3208 may perform at this stage, the MMU computertransmits the medical device specific delivery information, such as thepump settings, to the infusion pump 3130, 3230. The infusion pump 3130,3230 includes a medical device memory for storing the medical devicespecific delivery information for use in programming the infusion pump3130, 3230 to deliver the medication 3100, 3200 to the patient 3104,3204. The infusion pump 3130, 3230 stores the settings in the pumpmemory, but in one embodiment does not display the settings on thedisplay 88 of the infusion pump 3130, 3230, and therefore the settingscannot be seen by the nurse 3132, 3232 when the settings are initiallystored in the pump memory. Alternatively, the programmed settings may bedisplayed on the display 88 of the pump 3130, 3230, but with a largecautionary warning that the settings are merely preliminary. Theinfusion pump 3130, 3230 then transmits a confirmation signal to the MMUcomputer 3108, 3208 that the infusion pump 3130, 3230 received themedical device specific delivery information, such as the pump settingsfor performing the infusion for the patient 3104, 3204 with themedication 3100, 3200. Once the MMU computer 3108, 3208 receives thisconfirmation signal, the MMU computer 3108, 3208 transmits aconfirmation signal to the POC computer 3124, 3224 and/or the POC client3126, 3226 that the medical device specific delivery information wasreceived by the infusion pump 3130, 3230.

Once the POC computer 3124, 3224 and/or the POC client 3126 receivesthis confirmation signal, the software running on one or more of the POCsystem 3125, 3225 computers is structured to transmit a request to thePOC client 3126, 3226 to prompt the nurse 3132, 3232 to read or scan theidentifier, such as a barcode, on the patient's identification wristband112. Thus, at this point, the nurse 3132, 3232 uses the POC client 3126,3226 to scan the identifier, such as a barcode on the patient wristband112 to obtain patient specific identification information 3103, 3203 onthe identifier, and the POC client 3126, 3226 processes and/or sends ortransmits the patient specific identification information 3103, 3203 tothe POC computer 3124, 3224 for receipt by the POC computer 3124, 3224.

After receipt of patient specific identification information, the POCcomputer 3124, 3224 and/or the POC client 3126 does a “right patient”check. Specifically, the POC computer 3124, 3224 and/or the POC client3126 compares at least one of the received drug container specificidentification information and the patient specific identificationinformation to the stored medication order information within the memoryassociated with the POC computer 3124, 3224 and/or the POC client 3126.If the received drug container specific identification informationand/or the patient specific identification information matches thestored medication order information within the memory, then the POCcomputer 3124, 3224 and/or the POC client 3126 transmits a medicationdelivery initiation signal to the MMU computer 3108, 3208, which tellsthe MMU computer 3108, 3208 to “start the infusion.” If all otherapplicable checks occurring at the MMU computer 3108, 3208, as describedwithin the present specification, are satisfied then the MMU computer3108, 3208 transmits a second medication delivery initiation signal tothe infusion pump 3130, 3230 to communicate to the infusion pump 3130,3230 that it is “safe” to initiate the delivery of the medication to thepatient 3104, 3204 using the medical device specific deliveryinformation, such as infusion parameters, previously transmitted to andreceived by the infusion pump 3130, 3230.

Software running on the infusion pump 3130, 3230 will then consider itsafe to display the medical device specific delivery information, suchas the infusion parameters for the medication order for the patient, onthe display 88 of the infusion pump 3130, 3230 (without any warning thatthe settings are merely preliminary), and will do so. The infusion pump3130, 3230 can be programmed to force the caregiver 3132, 3232 tomanually press one or more buttons or receive some affirmativeindication from the caregiver 3132, 3232 that the medical devicespecific delivery information on the display 88 is confirmed as correctfor that particular patient 3104, 3204 and that particular medication3100, 3200, etc. As described in prior embodiments, the MMU computer3108, 3208 receives infusion pump 3130, 3230 status information from theinfusion pump 3130, 3230. The MMU computer 3108, 3208 transmits thisinfusion pump 3130, 3230 status information along to the POC computer3124, 3224 and/or POC client 3126 for display on the POC client 3126,3226. The MMU computer 3108, 3208 stores this information in a memoryassociated with the MMU computer 3108, 3208 before forwarding along tothe POC computer 3124, 3224 and/or the POC client 3126, 3226.Alternatively, the MMU computer 3108, 3208 can store the infusion pump3130, 3230 status information in an associated memory and wait until thePOC system 3125, 3225 requests or polls the MMU computer 3108, 3208 torequest the MMU computer 3108, 3208 to send the pump status informationto the POC system 3225 for display on the POC client 3126, 3226, forviewing by the caregiver 3132, 3232.

With continued reference to FIGS. 1 and 2, another embodiment of themedication administration system and method will now be described. Thisfurther embodiment is similar to the previous described embodiment.However, instead of waiting to read the identifier on the wristband 112of the patient 3104, 3204 until after the medical device specificdelivery information is transmitted to the infusion pump 3130, 3230, thecaregiver 3132, 3232 scans the patient wristband identifier just afterscanning the identifier on his or her own caregiver badge 116. The nurse3132, 3232 can scan the patient wristband 112 before scanning thenurse's badge 116 or even after scanning the identifier 102 on themedication container 3102, 3202. The order is not significant, exceptthat the system and method can be arranged to comply with a set of tasksand steps which are comfortable for the caregiver 3132, 3232 to follow.Thus, after the nurse scans the identifiers on the caregiver badge 116,the patient wristband 112, the medication container 3102, 3202, and theinfusion pump 3130, 3230, but not necessarily in any particular orderexcept for ease of use by a caregiver 3132, 3232, using the drugcontainer specific identification information 3101, 3201 from the drugcontainer 3102, 3202, the POC computer 3124, 3224 and/or POC client3126, 3226 finds or retrieves from the memory associated with the POCcomputer 3124, 3224 and/or the POC client 3126, 3226, the medicationorder associated with the drug container specific identificationinformation, which contains medical device specific delivery informationfor use in programming the infusion pump 3130, 3230. The POC computer3124, 3224 and/or the POC client 3126 then sends or transmits themedical device specific identification information, such as the pump ID,the caregiver specific identification information, such as the nurse'sID, the patient specific identification information, such as the patientID, the order ID obtained or retrieved from one of the drug containerspecific identification information or from the associated medicationorder stored in the memory associated with the POC computer 3124, 3224and/or POC client 3126, and the medical device specific deliveryinformation, such as the pump settings for the order, to the MMUcomputer 3108, 3208.

In addition to or separate from other actions or functions which the MMUcomputer 3108, 3208 may perform at this stage, software running on theMMU computer transmits the medical device specific delivery information,such as the pump settings, and the patient specific identificationinformation, such as the patient ID to the infusion pump 3108, 3230. Theinfusion pump 3130, 3230 stores this information in the pump memory, butdoes not display this information on the display of the infusion pump3130, 3230, and therefore this information cannot be seen by the nurse3132, 3232. The infusion pump 3130, 3230 then transmits a confirmationsignal to the MMU computer 3108, 3208 that the infusion pump 3130, 3230received the medical device specific delivery information and thepatient specific identification information. Once the MMU computer 3108,3208 receives this confirmation signal, the MMU computer 3108, 3208transmits a confirmation signal to the POC system 3125, 3225, morespecifically the computer 3124, 3224 and/or the POC client 3126, 3226that the medical device specific delivery information and the patientspecific identification information was received by the infusion pump3130, 3230.

Once the POC computer 3124, 3224 and/or the POC client 3126 receivesthis confirmation signal, the software running on the POC computer 3124,3224 and/or the POC client 3126 does a “right patient” check.Specifically, the POC computer 3124, 3224 and/or the POC client 3126compares at least one of the received drug container specificidentification information and the patient specific identificationinformation to the stored medication order information within the memoryassociated with the POC computer 3224 and/or the POC client 3126, 3226.If the received drug container specific identification informationand/or the patient specific identification information matches thestored medication order information within the memory associated withthe POC computer 3124, 3224 and/or the POC client 3126, 3226, then thePOC computer 3124, 3224 and/or the POC client 3126 transmits amedication delivery initiation signal to the MMU computer 3108, 3208,which tells the MMU computer 3108, 3208 to “start the infusion.” If allother applicable checks occurring at the MMU computer 3108, 3208, asdescribed within the present specification, are satisfied, then the MMUcomputer 3108, 3208 transmits a second medication delivery initiationsignal to the infusion pump 3130. 3230 to communicate to the infusionpump 3130, 3230 that it is “safe” to initiate the delivery of themedication to the patient 3104, 3204 using the medical device specificdelivery information, such as infusion parameters, previouslytransmitted to and received by the infusion pump 3130, 3230.

Software running on the infusion pump 3130, 3230 will then consider itsafe to display the medical device specific delivery information, suchas the infusion parameters for the medication order for the patient, onthe display of the infusion pump 3130, 3230, and will do so. Theinfusion pump 3130, 3230 can be programmed to force the caregiver 3132,3232 to manually press a button or receive some indication from thecaregiver 3132, 3232 that the medical device specific deliveryinformation on the display is correct for that particular patient 3104,3204 and that particular medication 3100, 3200, etc. As described inprior embodiments, the MMU computer 3108, 3208 receives infusion pump3130, 3230 status information from the infusion pump 3130, 3230. The MMUcomputer 3108, 3208 transmits this infusion pump 3130, 3230 statusinformation along to the POC computer 3124, 3224 and/or the POC client3126 for display on the POC client 3126, 3226. The MMU computer 3108,3208 stores this information in a memory associated with the MMUcomputer 3108, 3208 before forwarding along to the POC system 3125,3225. Alternatively, the MMU computer 3108, 3208 can store the infusionpump 3130, 3230 status information in an associated memory and waituntil the POC computer 3124, 3224 and/or the POC client 3126, 3226requests the MMU computer 3108, 3208 to request the MMU computer 3108,3208 to send the pump status information to the POC computer 3124, 3224and/or the POC client 3126 for display on the POC client 3126, 3226, forviewing by the caregiver 3132, 3232.

With continued reference to FIGS. 1 and 2, another embodiment of themedication administration system and method will now be described.However, for the purposes of this embodiment, in addition to theinfusion pump 3130, 3230 communicating directly with the MMU computer3108, 3208, the infusion pump 3130, 3230 also communicates directly withthe POC computer 3124, 3224 and or the POC client 3126, 3226, which canbe referred to as a peer to peer arrangement. In this embodiment, theMMU computer 3108, 3208 can be considered as a “marriage” broker,supplying an availability state signal or marrying a computer of the POCsystem 3125, 3225 to an infusion pump 3130, 3230 when the infusion pumpis “available” for performing an infusion function with a patient 3104,3204. The status and availability of the infusion pumps 3130, 3230 istracked by the MMU computer 3108, 3208. Communication from the pump3130, 3230 to the POC system 3125, 3225 is routed through the MMU server3108, 3208 to allow for centralized monitoring of infusions by the MMUserver 3130, 3230 while freeing up the POC system 3125, 3225 for otherprocessing tasks.

In this embodiment, the caregiver uses the POC client 3126, 3226 to scanthe identifiers on the caregiver badge 116, the patient wristband 112,the medication container 3102, 3202, and the infusion pump 3130, 3230 orchannel thereof, but not necessarily in any particular order except forease of use by a caregiver 3132, 3232. At this point the POC computer3124, 3224, or even the POC thick client 3126, can perform one or moreof the “five rights” checks, including comparing the received drugcontainer specific identification information 3101, 3201 and/or thepatient specific identification information 3103, 3203 to storedmedication order information stored within the memory associated withthe POC computer 3124, 3224 and/or POC client 3126. At this point, thenurse 3132, 3232 can review the medical device specific deliveryinformation through the POC client 3126, 3226 and make any changesdeemed necessary by the nurse 3132, 3232. The medical device specificdelivery information 3131, 3231 can also be checked by, or againstinformation which is stored in, the MMU computer 3108, 3208, in a mannersimilar to prior embodiments, such as for drug-drug interaction, dosinglimits, and/or other checks. Alternatively, these comparisons and checkscan be performed later in the process of the present embodiment.

The POC computer 3124, 3224 and/or the POC client 3126 then transmits arequest to the MMU computer 3108, 3208 for permission to communicatewith the infusion pump 3130, 3230 which has been scanned by the nurse3132, 3232. This request is performed at least because the infusion pump3130, 3230 may already be in communication in another server-clientrelationship with the POC server 3124, 3224 and/or the POC client 3126,or turned off, out of communication, or the infusion pump 3130, 3230 maybe communicating with a separate POC sever or other system, or may beoperating an infusion to the same patient or another patient. Thus, forpreventing interruption of other communications and operations, and forother understandable safety reasons, the MMU computer 3108, 3208determines if the infusion pump 3130, 3230 is available to communicatewith the POC computer 3124, 3224 and/or the POC client 3126 and receivethe medical device specific delivery information. If the MMU computer3108, 3208 determines that the infusion pump 3130, 3230 is notavailable, the MMU computer 3108, 3208 transmits a non-available statesignal to the POC computer 3124, 3224 and/or the POC client 3126, 3226,and the nurse 3132, 3232 is prevented from proceeding further with theinfusion procedure or workflow. If the MMU computer 3108, 3208determines that the infusion pump 3130, 3230 is available, then the MMUcomputer 3108, 3208 generates and transmits an available state signalfor the medical device 3130, 3230. In one embodiment, the availablestate signal can include key information such as an encrypted securitytoken which is generated by the MMU computer 3108, 3208. The keyinformation can alternatively be separate from the available statesignal. The MMU computer 3108, 3208 then transmits the key information,such as an encrypted security token, along with the IP address ofinfusion pump 3130, 3230 to the POC computer 3124, 3224 and/or the POCclient 3126, 3226. The MMU computer 3108, 3208 also transmits the keyinformation, such as an encrypted security token to the infusion pump3130, 3230. Each key information, such as an encrypted security tokencan include an age or have an age associated therewith, which after apredetermined amount of time, such as two minutes, will time out orexpire and prevent the key information, such as an encrypted securitytoken from being useable. In one embodiment, each time the keyinformation, such as an encrypted security token is used within acommunication, the age can be reset or renewed. Alternatively, the keyinformation, such as an encrypted security token can have a time stampcreated at the time of generation by the MMU computer 3108, 3208, whichcan be used compared against an actual time of day when the keyinformation, such as an encrypted security token is attempted to beused. The comparison of the time stamps to the time of day can beperformed at the POC computer 3124, 3224, the POC client 3126, 3226and/or at the infusion pump 3230, based on time of day tracking at thesedevices. The infusion pump 3130, 3230 can have a real-time clock forthis purpose.

If an available state signal, which can include key information for theinfusion pump 3130, 3230 is received by the POC computer 3124,3224 andor the POC client 3126, 3226, the POC computer 3124, 3224 and/or the POCclient 3126, 3226 can then retrieve the medical device specific deliveryinformation and any other information that may be needed by the infusionpump 3130, 3230, and transmit this information along with the keyinformation, such as an encrypted security token to the infusion pump3130, 3230, using the IP address of the infusion pump 3130, 3230received from the MMU computer 3108, 3208, for use in programming theinfusion pump 3130, 3230 to infuse the medication 3100, 3200 to thepatient 3104, 3204. If the POC computer 3124, 3224 has not performed anyor completed “five rights” checking, the POC computer 3124, 3224 and/orthe POC client 3126, 3226 will compare the received drug containerspecific identification information and/or the patient specificidentification information to the stored medication order informationwithin the memory associated with the POC computer 3124,3224 and/or POCclient 3126, before retrieving and transmitting the medical devicespecific delivery information to the infusion pump 3130, 3230 along withthe key information, such as an encrypted security token, for use inprogramming the medical device 3130, 3230 to deliver the medication3100, 3200 to the patient 3104, 3204. Alternatively, the POC computer3124, 3224 and/or the POC client 3126, 3226 can transmit the medicaldevice specific delivery information to the infusion pump 3130, 3230without the key information, such as an encrypted security token andwait until after “five rights” checking is completed by the POC computer3124, 3224 and/or the POC client 3126, 3226 before transmitting the keyinformation to the infusion pump 3130, 3230.

In one embodiment, if the medical device specific delivery informationis transmitted to the infusion pump 3130, 3230 without the securitytoken, the infusion pump 3130, 3230 will automatically reject themedical device specific delivery information, and will prevent theinfusion pump 3130, 3230 from being programmed utilizing the medicaldevice specific delivery information retrieved by the POC computer 3124,3224 and/or the POC client 3126, 3226. In one embodiment, the infusionpump 3130, 3230 compares encrypted security tokens received from the POCcomputer 3124, 3224 (and/or the POC client 3126, 3226) and from the MMUcomputer 3108, 3208 to determine if the infusion pump 3130, 3230 shouldbe programmed according to the received medical device specific deliveryinformation. If the key information, such as the encrypted securitytokens do not match or correspond in a predetermined way, the infusionpump 3130, 3230 will automatically reject the medical device specificdelivery information, and will prevent the infusion pump 3130, 3230 frombeing programmed utilizing the medical device specific deliveryinformation sent by the POC system 3125, 3225 (retrieved by the POCcomputer 3124, 3224 and/or the POC client 3126, 3226). In oneembodiment, until the above checks occur at the infusion pump 3130,3230, the medical device specific delivery information will be stored inthe infusion pump memory and will not be displayed until after suchchecks occur and are affirmative.

The infusion pump 3130, 3230 status information functionality can beperformed according to embodiments described above, through the MMUcomputer 3108, 3208 and to the POC computer 3124, 3224 and/or the POCclient 3126, 3226. Alternatively, the infusion pump 3130, 3230 statusinformation can be sent directly to the POC computer 3124, 3224 and/orthe POC client 3126, 3226 for display on the display of the POC client3126, 3226, or when the POC system 3225 (computer 3124, 3224 and/or POCclient 3126, 3226) requests status from the infusion pump 3130, 3230.Even if the infusion pump 3130, 3230 status information is to be sentdirectly to the POC system 3125, 3225, the infusion pump 3130, 3230status information can also be sent directly to the MMU computer 3108,3208 according to prior embodiments described herein.

The present embodiment prevents the MMU computer 3108, 3208 from havingto process as much information, as compared to prior embodiments. Thepresent embodiment also improves the liveliness of the auto-programmingworkflow by using peer-to-peer communications between POC system 3125,3225 and the infusion pump 3130, 3230, circumventing MMU message queuingand any inherent disadvantages associated therewith.

Referring to flowcharts of FIGS. 7A and 7B in addition to FIGS. 1 and 2,another embodiment of the system and method of administering amedication 3100, 3200 to a patient 3104, 3204 using an infusion pump3130, 3230 is shown. Specifically, similar to the previous embodiment,when the POC system 3125, 3225 is auto-programming the infusion pump3130, 3230, the POC system 3125, 3225, including the POC computer 3124,3224 and/or the POC client 3126, 3226 requests the MMU 3108, 3208 forpermission to program the infusion pump 3130, 3230. Once this permissionis granted by the MMU computer 3108, 3208, the POC system 3125, 3225communicates directly with the infusion pump 3130, 3230 without MMUcomputer 3108, 3208 intervention. In this embodiment, a first processstep 3302 provides that the MMU computer 3108, 3208 continually receivesasynchronous (i.e. unsolicited, un-polled) status messages and eventlogs from the infusion pump 3130, 3230 and stores this information in anassociated memory for purposes of at least displaying infusion pump3130, 3230 status and generating reports.

In a second process step 3304, as in prior embodiments, the nurse 3132,3232 can start the workflow for automatically programming the infusionpump 3130, 3230 by using the POC system 3125, 3225 to scan theidentifier on the nurse's ID badge 116. In a third process step 3306,the POC system 3125, 3225 determines if the nurse 3132, 3232 is a validPOC system 3125, 3225 user. The POC system 3125, 3225 may also requirethe nurse 3132, 3232 to enter a password, and/or other information.

In a fourth process step 3308, the nurse 3132, 3232 at the POC system3125, 3225 then scans the identifier on the patient's wristband 112. Ina fifth process step 3310, the POC system 3125, 3225 then looks up thepatient 3104, 3204, at which time the POC computer 3124, 3224 and/or thePOC client 3126, 3226 can retrieve the patient status, such as theirrecorded condition, present medications being taken, and/or any otherinformation which may exist in that patient's EMAR, as well as retrievethe patient's medication orders, for administration.

In a sixth process step 3312, the nurse 3132, 3232 obtains the bag orcontainer 3102, 3202 of medication 3100, 3200, and scans the identifieron the identification label 102 on the container 3102, 3202. In aseventh process step 3314, the POC system 3125, 3225 performs variouschecks on the order or medication typically ensuring that the medicationwas, in fact, ordered, that it is the correct time to deliver themedication, that the patient has no known allergies or intolerancestoward the medication, that the medication will not interact adverselywith another medication the patient is receiving, and/or other “fiverights” and safety checks.

In an eighth process step 3316, the POC system 3125, 3225 determinesthat the medication is potentially “pump-able” and transmits a query tothe POC client 3126, 3226 asking the nurse 3132, 3232 if the nurse wantsto deliver the medication 3100, 3200 using an infusion pump 3130, 3230.The POC system 3225 can accept a yes/no response to the query, or thePOC computer 3124, 3224 and/or the POC client 3126, 3226 can accept aresponse of the nurse 3132, 3232 actually scanning an identifier for aninfusion pump 3130, 3230 channel. If the nurse 3132, 3232 scans theidentifier of the infusion pump 3230 channel as the response, the POCsystem 3125, 3225 receives a pump channel logical ID from the scannedbarcode identifier 92.

In a ninth process step 3318, the POC system 3125, 3225 transmits arequest to the MMU computer 3108, 3208 for the type of infusion pump3130, 3230 and the software revision for the infusion pump 3130, 3230based upon the given logical ID of the pump/pump channel. At this point,the POC system 3125, 3225 can then utilize the information concerningthe type of infusion pump 3130, 3230 and the software revision for theinfusion pump 3130, 3230 to adjust or tailor the workflow,communications, and the user interface itself (on the POC client 3126,3226 and elsewhere) so as to be appropriate for the type of infusionpump 3130, 3230 and the software revision for the infusion pump 3130,3230 being used.

In another variant 3318A of the ninth step, the POC system 3125, 3225may further include or transmit, concurrently with or separately fromthe pump type and software revision request, a request to the MMU 3108,3208 to provide the pump's program schema (i.e., the syntax of theprogram messages it accepts) from the MMU 3108, 3208 for the infusionpump 3130, 3230 based on the given pump/pump channel logical ID and/orthe pump type and/or software revision. The program pump schema is anXML schema that precisely defines the syntax for programs a particularpump 3130, 3230 will accept. In addition to defining the specificoptional and required information, the schema can define the requiredcharacteristics of such information, including but not limited toformat, maximum values, minimum values, decimal point placement, andnumber of digits or characters. The POC system 3125, 3225 can then usethis information to ensure that the program it sends to the pump 3130,3230 has the correct syntax. In other words, the pump program schema isbasically a template that the POC system 3125, 3225 can use as a guideto transform its medical device specific delivery information ormedication order information into information that is usable to programa particular pump 3130, 3230 of a given type and software revision.

In another variant 3318B of the ninth step, the POC system 3125, 3225may further include or transmit, concurrently with or separately fromthe pump type and software revision request, a request to the MMUcomputer 3108, 3208 to provide an actual software module or program(i.e., an executable software package) which the POC system 3125, 3225can run in its process space (POC computer 3124, 3224 or POC client3226) that will automatically translate the infusion pump program from adevice-neutral to a device-specific format. The program is translatorscript or executable code written in Java or another suitableprogramming language, which when executed by the POC system 3125, 3225will automatically convert, translate, or transform the medical devicespecific delivery information or medication order information from thePOC system 3125, 3225 into information that is usable to program thepump 3130, 3230. The translator program can be tailored for theparticular POC system 3125, 3225 in question by utilizing a POC systemID such as described below and is, of course, tailored to the specifictarget infusion pump 3130, 3230.

In an optional tenth process step 3320, the POC system 3125, 3225displays medication order and/or medication 3100, 3200 information onthe display of the POC client 3126, 3226, which can be tailored for theparticular pump 3130, 3230 type. The pump type or other informationabout the pump, such as software revision, schema, or translationidentifiers can also be displayed on the POC client 3126, 3226. Themedication and medication order information can be in POC system formator in infuser setting format.

In an optional eleventh process step 3322, the nurse 3132, 3232 at thePOC system 3125, 3225 can then adjust the infusion pump settings throughthe POC client 3126, 3226. In one embodiment, if a medication ID wasscanned from the identifier on the label 102 on the medication container3102, 3202, and the identifier does not include an order ID, then thenurse 3232 may have to enter the infusion pump 3230 settings fromscratch on the POC client 3126, 3226. The nurse 3232 then confirms thesettings indicating that the infusion should proceed to be programmedinto the pump 3130, 3230.

In a twelfth process step 3324, the POC system 3125, 3225 transmits arequests to the MMU computer 3108, 3208 requesting permission to programthe infusion pump 3130, 3230. With the request, the POC system 3125,3225 transmits the pump channel's logical ID, the POC system's ID, atleast some patient information (e.g. name, number, room, bed, etc.) atleast some order information (e.g., order ID, parameters for infusion,etc.) and some medication information (e.g., medication ID, medicationname, etc.). The MMU computer 3108, 3208 first ensures that the POCsystem 3125, 3225 is known based on the POC system ID provided.

In a thirteenth process step 3326, the MMU computer 3108, 3208 attemptsto translate the pump channel's logical ID into a physical IP address,using medical device information stored in a memory associated with theMMU computer 3108, 3208. The MMU computer 3108, 3208 has in its memory(as part of the status information it receives on a periodic or loopingbasis in step 3302 from various infusion pumps it is in communicationwith) an up-to-date look up or translation table of static pump logicalIDs and network pump IDs or IP addresses. In a fourteenth process step3328, the MMU computer 3108, 3208 then transmits a signal which “pings”the infusion pump 3130, 3230 to make sure the infusion pump 3130, 3230is online and available for an infusion. It is possible that theinfusion pump 3130, 3230 may not be available because it may becurrently infusing a different patient, the pump channel may already bein use, etc. This transmission can also request the infusion pump 3130,3230 to retrieve the very latest status information from the infusionpump 3130, 3230 and transmit this status information back to the MMUcomputer 3108, 3208 as a part of its ping response.

In a fifteenth process step 3330, assuming the pump channel is availablefor programming an infusion, the MMU computer 3108, 3208 generates asecurity key that the POC system 3125, 3225 will use to identify itself(the POC system 3125, 3225) to the infusion pump 3130, 3230. In oneembodiment, the POC system ID is included in the security key or token,which can be encrypted. In a sixteenth process step 3232, the MMUcomputer 3108, 3208 transmits the security key to the infusion pump3130, 3230. The infusion pump 3130, 3230 maintains list of security keyswithin the infusion pump 3130, 3230 memory. Every security key can havea finite predetermined lifetime, such as five minutes for example. Ifthe infusion pump 3130, 3230 does not receive any communication from theappropriate POC system 3125, 3225 for which the respective security keywas assigned and stored within the memory of the infusion pump 3130,3230, within lifetime of the stored security key, the security keyautomatically expires. Conversely, every time the infusion pump doesreceive a communication relating to a particular POC system 3125, 3225and thus to a particular security key stored in the infusion pumpmemory, the security key is renewed, and the finite lifetime is reset toits original time or some other increased finite time. The infusion pump3130, 3230 then transmits to the MMU computer 3108, 3208 anacknowledgement or confirmation signal, and the MMU computer 3108, 3208,in turn, transmits the security key and IP address to the POC system3125, 3225.

In a seventeenth process step 3334, the POC system 3125, 3225 thentransmits the medical device specific delivery information, such as theprogram settings, directly to the infusion pump 3130, 3230 using the IPaddress of the infusion pump 3130, 3230, including transmission of thesecurity key to the infusion pump 3130, 3230. In one embodiment, the POCsystem 3125, 3225 prompts the nurse 3132, 3232 through the POC client3126, 3226 to step over to the infusion pump 3130, 3230 to confirm theprogram settings on the display 88 of the pump. The program settings canbe transmitted to the infusion pump 3130, 3230 in the pump'sdevice-specific format.

In an eighteenth process step 3336, the infusion pump 3130, 3230receives the program settings and displays the program settings on thedisplay 88 of the infusion pump 3130, 3230. As mentioned, the nurse3132, 3232 can confirm the program settings on the pump 3130, 3230. Onceconfirmation occurs, and the infusion pump 3130, 3230 is programmed, theinfusion pump 3130, 3230 then expires the security key since theinfusion pump 3130, 3230 has been successfully programmed.Alternatively, the infusion pump 3130, 3230 could be designed so as notto immediately expire the security key. In this alternative, it would bepossibly to resend program settings in the event of communicationfailure or other error conditions. The infusion pump 3130, 3230 couldalways use the security key to ensure that it receives a completeprogram at most once. In either case, the infusion pump 3130, 3230transmits a confirmation or disposition signal to the POC system 3125,3225, including information indicating that the program settings wereaccepted as-is, accepted with edits, or rejected—along with, ifaccepted, the final program settings.

In a nineteenth process step 3338, the POC system 3125, 3225 may thenpoll the MMU computer 3108, 3208 for status information about aninfusion pump channel using the channel's logical ID. In a twentiethprocess step 3340, which can be a part of other steps, an infusion pump3130, 3230 will automatically expire a security key when the key'slifetime elapses without any communication from a POC system using thekey.

Referring to flowcharts of FIGS. 8A and 8B in addition to FIGS. 1 and 2,another embodiment of the system and method of administering amedication 3100, 3200 to a patient 3104, 3204 using an infusion pump3130, 3230 is shown. Specifically, this MMU server mediated embodimentis substantially similar to the previous embodiments where the medicaldevice specific delivery information, including a program, istransmitted to the infusion pump 3130, 3230 from the POC system 3125,3225 through the MMU computer 3108, 3208 before the patient 3104, 3204is positively identified. In the present embodiment, as described belowa subsequent updated program can be transmitted to the infusion pump3130, 3230, if necessary.

In this embodiment, a first process step 3502 provides that the MMUcomputer 3108, 3208 continually receives asynchronous (i.e. unsolicited,un-polled) status messages and event logs from the infusion pump 3130,3230 and stores this information in an associated memory for purposes ofat least displaying infusion pump 3130, 3230 status and generatingreports.

In a second process step 3504, as in prior embodiments, the nurse 3132,3232 can start the workflow for auto-programming of the infusion pump3130, 3230 by using the POC system 3125, 3225 to scan the identifier onthe nurse's ID badge 116. In a third process step 3506, the POC system3125, 3225 determines if the nurse 3132, 3232 is a valid user of the POCsystem 3125, 3225. The POC system 3125, 3225 may also require the nurse3132, 3232 to enter a password, and/or other information. In a fourthprocess step 3508, the nurse 3132, 3232 at the POC system 3125, 3225then scans the identifier on the patient's wristband 112. As will beunderstood based on the description below, the scanning of theidentifier on the patient's wristband 112 alternatively can be delayeduntil after programming the pump when the identifier is actually neededfor a “right patient” comparison.

In a fifth process step 3510, the nurse 3132, 3232 obtains the container3102, 3202 of medication 3100, 3200 and then scans the identifier on theidentification label 102 on the container 3102, 3202. The container IDcan be a universally unique order ID so that the POC system 3125, 3225can retrieve information about the associated medication order withouthaving to scan the patient ID on the patient wristband 112 or rely onsuch patient ID information for comparison purposes. In a sixth processstep 3512, the POC system 3125, 3225 performs various checks on theorder including checking the order ID, as in prior embodiments, but doesnot make any checks relative to the patient, as the patient wristbandmay not yet have been scanned to determine the identify of the patient.Alternatively, these order related checks can be deferred until afterthe tenth process step 3520, described below.

In a seventh process step 3514, the POC system 3125, 3225 determinesthat the medication is potentially “pump-able” and either transmits aquery to the POC client 3126, 3226 asking the nurse 3132, 3232 if thenurse wants to deliver the medication using an infusion pump 3130, 3230.The POC computer 3124, 3224 and/or the POC client 3126, 3226 can accepta yes/no response to the query or the POC system 3125, 3225 can accept aresponse of the nurse 3132, 3232 actually scanning an identifier 92 foran infusion pump 3130, 3230 or pump channel thereof. If the nurse 3132,3232 scans the identifier 92 of the infusion pump 3130, 3230 channel asthe response, the POC system 3125, 3225 receives a pump channel logicalID from the scanned barcode.

In an eighth process step 3516, the POC system 3125, 3225 transmits thepump channel's logical ID, the order ID, and the medical device specificdelivery information, such as the program (i.e. order) settings to theMMU computer 3108, 3208, and communicates to the MMU computer 3108, 3208that the MMU computer 3108, 3208 should send the medical device specificdelivery information to the infusion pump 3130, 3230. In a ninth processstep 3518, the MMU computer 3108, 3208 translates the pump channel'slogical ID into an IP address, as in prior embodiments.

In a tenth process step 3220, the MMU computer 3108, 3208 transmits themedical device specific delivery information, including the program tothe infusion pump 3130, 3230. The infusion pump 3130, 3230 stores thisinformation in the pump memory for use in programming the pump to infusethe medication into the patient. The infusion pump 3130, 3230 can send aconfirmation to the MMU computer 3108, 3208 that it received thisinformation. The MMU computer 3108, 3208 then transmits to the POCsystem 3125, 3225 that the medical device specific delivery informationhas been sent to the infusion pump 3130, 3230.

In an eleventh process step 3522, the nurse 3132, 3232 checks the orderinformation and in a twelfth step 3524 can adjust and confirm themedical device specific delivery information, such as the programsettings through the POC system 3125, 3225, such as through the POCclient 3126, 3226.

In a thirteenth process step 3526, the POC system 3125, 3225 transmitsan updated medical device specific delivery information, such as anupdated pump program including the pump channel's logical ID, the orderID, and a program update to the MMU computer 3108, 3208. If the nurse3132, 3232 made no changes to the medical device specific deliveryinformation, then this transmission is an “empty trigger” to the MMUcomputer 3108, 3208, which merely instructs the MMU computer 3108, 3208to transmit to the infusion pump 3130, 3230 to continue with thepreviously sent medical device specific delivery information/program.The POC system 3125, 3225 might display a message, such as through thePOC client 3126, 3226, instructing the nurse 3132, 3232 to review andconfirm the medical device specific delivery information on the display88 of the infusion pump 3130, 3230.

In a fourteenth process step 3528, the MMU computer 3108, 3208 againtranslates the logical ID into an IP address. In a fifteenth processstep 3530, the MMU computer 3108, 3208 transmits the updated medicaldevice specific delivery information, such as the updated program to theinfusion pump 3130, 3230, instructing the infusion pump 3130, 3230 toactually implement the medical device specific delivery information. Ina sixteenth process step 3532, the infusion pump 3130, 3230 receives themedical device specific delivery information and displays the medicaldevice specific delivery information on the display 88 of the infusionpump 3130, 3230. The nurse 3132, 3232 confirms the medical devicespecific delivery information at the infusion pump 3130, 3230 byperforming some affirmative act at the infusion pump 3130, 3230. Theinfusion pump 3130, 3230 transmits to the MMU computer 3108, 3208 adisposition or acknowledgment including how the medical device specificdelivery information was disposed of (accepted as is, accepted withedits, or canceled), and the MMU computer 3108, 3208 transmits thisinformation to the POC system 3125, 3225 along with the final medicaldevice specific delivery information settings.

In a seventeenth process step 3534, the POC system 3125, 3225 performs a“right patient” check as a part of the “five rights” checking. At thistime any other checking on the order (e.g. right time, allergies,drug-drug interactions, etc.) can also be performed.

In an eighteenth process step 3536, the POC system 3125, 3225 may thenpoll the MMU computer 3108, 3208 for status information about aninfusion pump channel using the channel's logical ID.

Referring to flowcharts of FIGS. 9A and 9B in addition to FIGS. 1, 2 and5, another embodiment of the system and method of administering amedication 3100, 3200 to a patient 3104, 3204 using an infusion pump3130, 3230 is shown. Specifically, this MMU server mediated embodimentis substantially similar to the previous embodiments where the medicaldevice specific delivery information, including a program, istransmitted to the infusion pump 3130, 3230 from the POC system 3125,3225 through the MMU computer 3108, 3208 before the patient 3104, 3204is positively identified. This embodiment is similar to the embodimentof FIGS. 8A and 8B in the first through the twelfth process steps3602-3624. However, instead of the nurse 3132, 3232 making programadjustments at the POC system 3125, 3225, in a thirteenth process step3626, adjustments are made by the nurse 3132, 3232 using the userinterface 86 and the display 88 of the pump. In an fourteenth processstep 3628, the POC system 3125, 3225 may then poll the MMU computer3108, 3208 for status information about an infusion pump channel usingthe channel's logical ID. Thus, the POC system learns of any programadjustments made at the pump 3130, 3230. This embodiment advantageouslyhas fewer steps yet allows for program adjustments. Any adjustments madewill also be subject to the safety limits of the drug library of thepump and will give the caregiver immediate alarm feedback if theadjusted pump program settings are not within such limits.

With reference to FIGS. 10A and 10B and FIGS. 1 and 2, another servermediated embodiment is shown. This embodiment, which is called a servermediated “unopened letter” programming model, is similar to thepreviously described server mediated embodiments through the first sevenprocess steps 3702-3714. In a eighth process step 3716, the POC system3125, 3225 transmits a request to the MMU computer 3108, 3208 for thetype of infusion pump 3130, 3230 based upon the given logical ID of thepump/pump channel. At this point, the POC system 3125, 3225 can thenutilize the information concerning the type of infusion pump 3130, 3230to adjust or tailor the workflow, communications, and the user interfaceitself (on the POC client 3126, 3226 and elsewhere) so as to beappropriate for the type of infusion pump 3130, 3230 being used. In aninth process step 3718, the POC system 3125, 3225 checks the patient IDor performs a “right patient” check as a part of the “five rights”checking. The right patient check and other checks alternatively can bepostponed until just prior to the final confirmation of order settingsin step fifteen described below. In a tenth process step 3720, the POCsystem 3125, 3225 performs any additional “five rights” checking and/orother checking on the order (e.g. right time, allergies, drug-druginteractions, etc.). In an eleventh process step 3722, the nurse 3132,3232 can adjust and confirm the medical device specific deliveryinformation, such as the program settings through the POC system 3125,3225, such as through the POC client 3126, 3226.

In a twelfth process step 3724, the POC system 3125, 3225 sends ortransmits the medical device specific identification information, suchas the pump or pump channel ID, the caregiver specific identificationinformation, such as the nurse's ID, the patient specific identificationinformation, such as the patient ID, the order ID and the medical devicespecific delivery information, such as the pump settings for the order,to the MMU computer 3108, 3208.

In a thirteenth process step 3726, the MMU 3108, 3208 bundles at leastthe pump settings for the order and optionally any of the otherinformation received from the POC system 3125, 3225 into a sealedprogram information letter and assigns it a unique letter ID. In afourteenth process step 3728, the MMU 3108, 3208 transmits the sealedprogram information letter and letter ID to the pump 3130, 3230. Thepump 3130, 3230 receives the letter and acknowledges to the MMU 3108,3208 that the letter was received, but cannot open the letter except inresponse to a unseal letter message from the MMU 3108, 3208. The MMU3108, 3208 sends the letter ID to the POC system 3125, 3225.

In a fifteenth process step 3730, the nurse 3132, 3232 confirms theorder settings at the POC client 3126, 3226. In a sixteenth process step3732, the nurse 3132, 3232 presses a button on the POC client 3126, 3226to transmit a signal from the POC system 3125, 3225 to the MMU 3108,3208 to proceed with the program for the given letter ID. In aseventeenth process step 3734, the MMU 3108, 3208 transmits a command tothe pump 3130, 3230 to unseal the program pump information letterassociated with the given letter ID. In an eighteenth step 3736, thepump 3130, 3230 unseals the program pump letter, sets the infusionsettings in its memory and displays them, then sends an acknowledgementto the MMU 3108, 3208, which in turn transmits an acknowledgement to thePOC system 3125, 3225. As in previously described embodiments, the POCsystem 3125, 3325 polls the MMU 3108, 3208 to get pump statusinformation in a nineteenth step 3738.

Referring to FIGS. 1, 2, 11A and 11B, another embodiment of the systemand method of administering a medication 3100, 3200 to a patient 3104,3204 using an infusion pump 3130, 3230 is shown. In this embodiment, theinfusion pump 3130, 3230 pulls its program information from a remotecomputer within the system in response to a request from the nurse 3132,3232 at the infusion pump 3130, 3230.

In this embodiment, a first process step 3802 provides that the MMUcomputer 3108, 3208 continually receives asynchronous (i.e. unsolicited,un-polled) status messages and event logs from the infusion pump 3130,3230 and stores this information in an associated memory for purposes ofat least displaying infusion pump 3130, 3230 status and generatingreports. Alternatively, the MMU computer 3108, 3208 can poll theinfusion pump 3130, 3230 and synchronously receive information from theinfusion pump 3130, 3230.

In a second process step 3804, as in prior embodiments, the nurse 3132,3232 can optionally start the workflow for auto-programming of theinfusion pump 3130, 3230 by using the POC system 3125, 3225 to scan theidentifier on the nurse's ID badge 116. In a substep 3805, the POCsystem 3125, 3225 determines if the nurse 3132, 3232 is a validauthorized user of the POC system 3125, 3225. This enhances patientsafety by preventing unauthorized infusions and facilitates electronicdocumentation of infusion orders administered. The POC system 3125, 3225may also require the nurse 3132, 3232 to enter a password, and/or otherinformation at the POC system 3125, 3225 or at the infusion pump 3130,3230.

In a third process step 3806, the nurse 3132, 3232 at the POC system3125, 3225 scans the identifier on the patient's wristband 112. Theresultant patient ID, which may be a medical record number, an accountnumber or some other identifier that the care facility uses topositively identify the patient, is retained in a memory in the POCsystem 3125, 3225.

In a fourth process step 3808, the nurse 3132, 3232 obtains thecontainer 3102, 3202 of medication 3100, 3200 and scans the identifier3101, 3201 on the identification label 102 on the container 3102, 3202.The container ID 3101, 3201, which may comprise machine-readable indiciasuch as a bar code, RFID tag, or the like, can be a universally uniqueorder ID so that the POC system 3125, 3225 can retrieve informationabout the associated medication order without having to scan the patientID on the patient wristband 112 or rely on such patient ID informationfor comparison purposes. Alternatively, the container ID can be acomposite ID that includes patient ID or some portion thereof and anorder ID related to that particular patient. Alternatively, thecontainer ID can be an absolute or unique pharmacy order identifier thatcan be generated by the order entry or pharmacy information systems.Alternatively, for commonly used containers that are stocked on the wardor patient care floor, like dextrose, saline or other solutions, thecontainer ID may be a medication ID that includes onlymedication-specific information, including but not limited to medicationname, concentration (if applicable) and volume.

In a fifth process step 3810, the POC system 3125, 3225 determines thatthe medication is potentially “pump-able” and either transmits a queryto the POC client 3126, 3226 asking the nurse 3132, 3232 if the nursewants to deliver the medication using an infusion pump 3130, 3230. ThePOC computer 3124, 3224 and/or the POC client 3126, 3226 can accept ayes/no response to the query or the POC system 3125, 3225 can accept aresponse of the nurse 3132, 3232 actually scanning an identifier 92 foran infusion pump 3130, 3230 or pump channel thereof. If the nurse 3132,3232 scans the identifier 92 of the infusion pump 3130, 3230 channel asthe response, the POC system 3125, 3225 receives a pump channel logicalID from the scanned barcode and stores it in memory.

In an optional alternative sixth process step 3812, the POC system 3125,3225 transmits a request to the MMU computer 3108, 3208 requesting thepump type of infusion pump 3130, 3230 based upon the given logical ID ofthe pump/pump channel. In response, the MMU computer 3108, 3208transmits or provides to the POC system 3125, 3225 the pump typecorresponding to the logical ID of the scanned infusion pump or pumpchannel. The POC system 3125, 3225 can then tailor its subsequentworkflow to the particular type of pump 3130, 3230. For example,different prompts, checks, screens, and warnings may be provided by thePOC system 3125, 3225 for syringe, peristaltic, cassette, generalinfusion, elastomeric and patient controlled analgesia pumps.

In a seventh process step 3814, the POC system 3125, 3225 checks thepatient ID or performs a “right patient” check as a part of the “fiverights” checking. The right patient check and other checks alternativelycan be postponed until just prior to adjustment or the finalconfirmation of order settings at the pump 3130, 3230 in step 3830described below (the program settings will have been received at thepump). The POC system 3125, 3225 can also perform additional checkingbased on the patient ID, order ID and/or the container ID (e.g. righttime, allergies, drug-drug interactions, etc.).

In an optional eighth process step 3816, the nurse 3132, 3232 can adjustand confirm the medical device specific delivery information, such asthe program settings through the POC system 3125, 3225, for examplethrough the POC client 3126, 3226. In a ninth process step 3818, the POCsystem 3125, 3225 submits pump program information including agenerically formatted (non-pump specific) pump program and the pumpchannel logical ID to the MMU server 3108, 3208. It is important to notethat the generic pump program is incapable of operating the pump.

In a tenth process step 3820, the MMU server 3108, 3208 gets from itsmemory the pump type corresponding to the logical ID of the scannedinfusion pump or pump channel, if step 3812 was previously omitted. Ofcourse, if step 3812 was previously executed, the pump type informationcould be included in the pump program information provided to the MMU3108, 3208 by the POC system 3125, 3225 instead of or in addition to thepump channel logical ID. The MMU 3108, 3208 uses the pump typeinformation and the generic pump program to generate a specific pumpprogram that is acceptable to the particular type of pump. In otherwords, the MMU 3108, 3208 translates the generic program into onespecific to the particular type of pump 3130, 3230. The MMU 3108, 3208converts the logical ID of the scanned pump 3130, 3230 to a pump IPaddress by consulting a dynamic IP address lookup table in the memory ofthe MMU 3108, 3208. The MMU 3108, 3208 does not download the program tothe pump 3130, 3230 in response to the above steps. Instead, the MMU3108, 3208 holds onto the pump program and acts like a post officeholding a letter addressed to the pump 3130, 3230.

The MMU 3108, 3208 can also perform additional functions of establishingand monitoring time stamps on pump programs, as well as managingmultiple infusion programs destined for the same pump 3130, 3230.Programs can be made available to the same pump 3130, 3230 on afirst-in-first-out (FIFO) basis, last-in-first-out (LIFO) or otherpriority basis. For example, boluses might be prioritized for deliverybefore maintenance doses and “crash cart” or “code blue” response drugsmight be given top priority. LIFO can be used to insure that only themost recent or most recently modified order is available to the pump3130, 3230. The MMU 3108, 3208 can automatically expire unutilized pumpprograms or send alarms or error messages to the pump 3130, 3230 and/orPOC system 3125, 3225 when a time stamp from the MMU or POC systemindicates a program age greater than a predetermined program age. Thus,stale, superseded, or out-of-date orders can be removed from the queue.

In an eleventh process step 3822, the MMU 3108, 3208 sends a message tothe pump 3130, 3230 stating that a pump program is available for thepump to pull. Returning to the post office analogy, the MMU 3108, 3208tells the pump 3130, 3230, “You have mail.” The pump 3130, 3230 displaysa message on its display 88 that tells the nurse 3132, 3232 to load theprogram when ready. The MMU 3108, 3208 sends a message to POC system3125, 3225 indicating that it successfully received the generic pumpprogram, translated the generic pump program into a pump-specificprogram, and advised the pump 3130, 3230 of the availability of thespecific pump program. The last-mentioned message from the MMU 3108,3208 signals the conclusion of the programming-related transactionsbetween the MMU 3108, 3208 and the POC system 3125, 3225. In an optionaltwelfth process step 3824, receipt of the message from the MMU 3108,3208 triggers the POC system 3125, 3225 to display a prompt on the POCclient 3126, 3226 instructing the nurse 3132, 3232 to go to the pump3130, 3230 to load the program on the pump 3130, 3230. This isespecially useful if the nurse 3132, 3232 is not presently looking atthe pump display 88 or proximate to it.

In a thirteenth process step 3826, the nurse 3132, 3232 uses the keypad86 or display 88 to instruct the pump 3130, 3230 to retrieve or pull thepump specific program from the MMU 3108, 3208. In a fourteenth processstep, the pump 3130, 3230 retrieves or pull the pump specific programfrom the MMU 3108, 3208. In a fifteenth process step 3830, the nurse3132, 3232 can adjust (modify) the program settings on the pump 3130,3230, if desired. Then, as illustrated in FIG. 4, the nurse 3132, 3232must confirm or cancel the settings by pressing an appropriate button onthe keypad 86 or touching a designated area of the display 88 when thedisplay is a touch screen. Upon confirmation, the pump 3130, 3230prompts the nurse 3132, 3232 with a second screen asking if they areready to start the infusion. Upon receipt of an affirmative responsefrom the nurse 3132, 3232, the pump 3130, 3230 runs the programmedinfusion.

In a sixteenth process step 3832, the POC system 3125, 3225 periodicallyrequests pump status information from the MMU 3108, 3208. The pumpstatus supplied by the MMU 3108, 3208 will either provide a positiveconfirmation that the program is running on the pump 3130, 3230 or anegative indication that the program has been rejected. Based upon thepump status or after a predetermined period of time has elapsed or bydirect intervention by the nurse 3132, 3232, the POC system 3125, 3225removes its prompt to load the program on the pump, if step 3824 wasexecuted. Alternatively, pump status messages can be supplied when thepump 3130, 3230 is on but not in an active pumping state, such as whenthe program settings have been received or when the program settingshave been confirmed but the pump 3130, 3230 has not been started by thenurse 3132, 3232.

The embodiment of FIGS. 11A and 11B is advantageous in that it isflexible enough to fit with the workflows of most clinical POC systems.This embodiment decouples the three major processors in the system (thepump, the MMU and the POC system), which allows for more efficientasynchronous communication, scales well if many pumps need to becommunicated with, and provides greater security by preventing the POCsystem 3125, 3225 from programming the pump 3130, 3230 directly withoutpermission from the MMU 3108, 3208. This embodiment is also flexibleenough to allow additional checks to be done by the MMU 3108, 3208, ifdesired. Advantageously program settings can be ready, waiting andperhaps even scheduled for a particular pump 3130, 3230 before the pumpis available.

Referring to FIGS. 1, 2 and 12, another embodiment of the system andmethod of administering a medication 3100, 3200 to a patient 3104, 3204using an infusion pump 3130, 3230 is shown. This embodiment is calledthe “medication selection” workflow and works with a stand alone scanneror one associated with a POC system 3125, 3225, MMU 3108, 3208, or apump 3130, 3230. In this embodiment, a first process step 3902 providesthat the MMU computer 3108, 3208 continually receives asynchronous (i.e.unsolicited, un-polled) status messages and event logs from the infusionpump 3130, 3230 and stores this information in an associated memory forpurposes of at least displaying infusion pump 3130, 3230 status andgenerating reports. Alternatively, the MMU computer 3108, 3208 can pollthe infusion pump 3130, 3230 and synchronously receive information fromthe infusion pump 3130, 3230.

In a second process step 3904, similar to the previously describedembodiments, the nurse 3132, 3232 can optionally start the workflow forauto-programming of the infusion pump 3130, 3230 by using the scanner toscan the identifier on the nurse's ID badge 116. The scanner is incommunication with the MMU server 3108, 3208 via a wireless connection,although a wired connection is also possible. The scanner can bedisposed on or in the pump 3130, 3230, tethered or wired thereto, or inwireless communication therewith directly or through the MMU 3108, 3208.

In a third process step 3906, the nurse 3132, 3232 uses the scanner toscan the identifier on the patient's wristband 112. The patient ID,which may be a medical record number, an account number or some otheridentifier that the care facility uses to positively identify thepatient, is retained in a memory in the scanner.

In a fourth process step 3908, the nurse 3132, 3232 obtains thecontainer 3102, 3202 of medication 3100, 3200 and uses the scanner toscan the identifier 3101, 3201 on the identification label 102 on thecontainer 3102, 3202. The container ID 3101, 3201, which may comprisemachine-readable indicia such as a bar code, RFID tag, or the like, canbe a universally unique order ID so that the HIS 3110, 3210 or POCsystem 3125, 3225 can retrieve information about the associatedmedication order without having to scan the patient ID on the patientwristband 112 or rely on such patient ID information for comparisonpurposes. Alternatively, the container ID can be a composite ID thatincludes patient ID or some portion thereof and an order ID related tothat particular patient. Alternatively, the container ID can be anabsolute or unique pharmacy order identifier that can be generated bythe order entry or pharmacy information systems. Alternatively, thecontainer ID may be a medication ID that includes onlymedication-specific information, including but not limited to medicationname, concentration (if applicable) and volume. For this example, themedication ID includes a generic, brand or package level identificationof the medication and its concentration as well. The container ID caninclude the order ID or the medication ID or both.

In a fifth process step 3910, if the nurse wants to deliver themedication using an infusion pump 3130, 3230, the nurse 3132, 3232 scansthe identifier 92 of the infusion pump 3130, 3230 channel and thescanner receives a pump channel logical ID or pump ID from the scannedbarcode and stores it in memory.

In a sixth process step 3912, the scanner sends a select medication onpump message to the pump 3130, 3230. The message may be routedindirectly through the MMU server 3108, 3208 or sent directly to thepump 3130, 3230. The message preferably includes the medication ID andmay include additional scanned information including the order ID, pumpor channel ID, and clinician ID. If the message was sent to the MMU3108, 3208 and only an order ID was provided, the MMU can assist in anoptional seventh process step 3914 wherein the medication (andconcentration) contained in the order are determined by requesting thisinformation or translation from the pharmacy information system 3116,3216 or order entry system 3114, 3214 of the HIS 3110, 3210 or accessinginformation already cached on the MMU 3108, 3208 by virtue of a separateMMU/HIS interface. Of course, this supplemental information ortranslation can be provided to the pump 3130, 3230 before, during orafter the rest of the selected medication information is sent to thepump, if it is needed. In an eighth process step 3916, the pump 3130,3230 receives the “select medication” message information and sends anacknowledgement to the MMU 3108, 3208. Once the medication and itsconcentration are known by the pump 3130, 3230, the pump 3130, 3230 canuse this information to automatically populate or fill in certain fieldsof programming screens, like medication and concentration, and set oridentify appropriate drug library rule sets based on the selected CCA.This provides considerable time-savings and adds a layer of safety withthe drug library rule sets.

In a ninth process step 3918, the nurse 3118, 3218 enters into the pump3130, 3230 the remaining pump program settings that have not beenautomatically populated. Advantageously in a tenth process step 3920,the pump 3130, 3230 checks the entered program settings against thepermissible settings specified in the drug library of the pump 3130,3230 and alerts the nurse of any impermissible settings. The nurse 3132,3232 can then adjust the pump program settings in an optional step 3922or override the alert in the case of soft limit violations. Any adjustedpump program settings are also checked against the drug library, andeventually the final program settings are viewed on the pump displayscreen 88 and confirmed by the nurse 3132, 3232 in process step 3924.

Then the nurse 3132, 3232 is presented with a start button on the screen88 to start the infusion in accordance with the final confirmedprogrammed pump settings. The pump 3130, 3230 continuously sends statusinformation (i.e., current settings and state) and event logs (i.e.,historical activity, alarms, alerts, overrides, etc.) to the MMU 3108,3208 pursuant to step 3902.

The embodiment of FIG. 12 is advantageous in that it saves the cliniciantime by automatically populating medication data on the pump, and in sodoing enhances the safety of drug administration by invoking or allowingthe nurse to quickly select drug library limits already provided on thepump. Many hospitals are non-profit institutions and cannot affordexpensive POC systems. However, scanners are far more affordable,ubiquitous and adaptable. The software requirements for this embodimentare more straightforward than many of the other more complex embodimentspreviously described. The medication is identified only once by all thesystems, which saves time and insures that all systems refer to the samemedication. This approach is also flexible enough to accommodatemedication which are bar coded with order ID or medication ID. Thelatter case would occur for emergency, “stat”, ad hoc, verbal orders, orother situations where the pharmacy information system has not hadsufficient time to process the order and label the medication with anorder ID barcode. Finally, this approach makes virtually no demands onthe POC system, making it easy for hospitals to implement or add on toexisting systems and workflows.

Referring to flowchart of FIG. 13 in addition to FIGS. 1 and 2, anotherembodiment of the system and method of administering a medication 3100,3200 to a patient 3104, 3204 using an infusion pump 3130, 3230 is shown.This embodiment is called the “medication selection with POC checking”workflow and includes steps 4002, 4004, 4006, 4008, 4010, 4012, 4014(optional), 4016 and 4018, which are the same as steps 3902, 3904, 3906,3908, 3910, 3912, 3914, 3916 and 3918 described above relative to FIG.12. In a tenth process step 4020, the pump 3130, 3230 automatically orupon direction of the nurse 3132, 3232 seeks to check the programinformation it has been provided. The medication ID, order ID, pump IDand program settings are communicated to the MMU 3108, 3208 by the pump3130, 3230. The MMU 3108, 3208 in turn communicates the check programmessage to the POC system 3125, 3225. The POC system 3125, 3225 checksthe program information for right patient, right drug, right time, rightroute, right dose, and other concerns such as right caregiver,allergies, drug-drug interactions, etc. as desired. Results are returnedto the MMU 3108, 3208 and the pump 3130, 3230 where they can be reportedto the user or displayed to the nurse 3132, 3232. The POC system 3125,3225 can also provide an alert directly to the nurse.

In an eleventh process step 4022, the nurse 3132, 3232 adjusts programsettings (for example, dose, rate, VTBI, duration, etc.) on the pump3130, 3230 to correct or override the alert condition. In a twelfthprocess step 4024, the pump 3130, 3230 checks the entered programsettings against the permissible settings specified in the drug libraryof the pump 3130, 3230 and alerts the nurse of any impermissiblesettings. The nurse 3132, 3232 can then adjust the pump program settingsin an optional step 4026 or override the alert in the case of soft limitviolations. Any adjusted pump program settings are also recheckedagainst the POC system requirements and the pump drug library in arepetitive loop, and eventually the final program settings are viewed onthe pump display screen 88 and confirmed by the nurse 3132, 3232 inprocess step 4028. Then the nurse 3132, 3232 is presented with a startbutton on the screen 88 to start the infusion in accordance with thefinal check and confirmed programmed pump settings. The pump 3130, 3230continuously sends status information (i.e., current settings and state)and event logs (i.e., historical activity, alarms, alerts, overrides,etc.) to the MMU 3108, 3208 pursuant to step 4002.

The embodiment of FIG. 13 has all the advantages of the basic medicationselection approach of FIG. 12, plus adds POC-based order and medication,as well as POC based checking of the actual infusion parametersprogrammed into the pump very close in time to the final confirmationand start of delivery.

FIGS. 1, 2, and 14 illustrate another embodiment of the presentinvention, which is called the “order lookup” workflow. In a step 4102of this embodiment, the MMU 3108, 3208 receives a “receive order”message from the HIS 3110, 3210 that includes the patient ID, the orderID, and order settings. Such messages could be received on a synchronous(i.e., polled) or asynchronous (i.e., event driven) basis directly fromthe HIS or indirectly via an interface engine (not shown). The order IDmay be universally unique across all patients or it may be unique onlywith respect to a given patient. In the latter case, the MMU 3108, 3208generates a universally unique or universal order ID from the patient IDand the order ID, then forms an orders table wherein the orderinformation is stored according to its universal order ID. For example,the patient ID can be a unique number assigned to the patient by thehospitals admission-discharge-and-transfer system 3112, 3212 and theorder ID can be a sequential number representing each medication orderwritten for that particular patient. The sequential number may includethe date and time the order is written, the date and time the order isto be administered, or both. The MMU 3108, 3208 generates an absolutelyunique or universal order ID and stores the order settings in a lookuptable at a cell or location associated with the assigned universal orderID.

The scanner in this embodiment can be associated with the POC system3125, 3225 as a POC client 3126, 3226. In a second process step 4104,the nurse 3132, 3232 scans his or her caregiver identification badge 116to input the clinician ID. In a third process step 4106, the nurse 3132,3232 scans the patient identification bracelet or badge 112 associatedwith the patient 3104, 3204 to input the patient ID. In a fourth processstep 4108, the nurse 3132, 3232 scans the label 102 on the medicationcontainer 3100 to obtain either a medication ID or order ID. The secondthrough fourth steps can be performed in any order that is convenientfor the caregiver 3132, 3232.

In a fifth process step 4110, the POC system 3125, 3225 checks those“rights” of medication management that it has sufficient informationfor, such as right/authorized clinician, right patient, rightmedication, right dose, right route/site, allergies, drug-druginteractions, etc. If anything is not right, the POC system 3125, 3225generates an alert to the nurse 3132, 3232, typically through the POCclient 3126, 3226 and gives the nurse an opportunity to correct theproblem or override the alert. Of course, as discussed above, some ofthe scanning and rights checking can be delayed until after the pumpprogram settings have been sent to the pump 3130, 3230. The POC system3125, 3225 determines that the medication should be delivered by an IVpump 3130, 3230. In a sixth process step 4112, the nurse 3132, 3232scans the pump/pump channel bar code label or ID 92 on the pump 3130,3230.

In a seventh process step 4114, the POC system 3125, 3225 sends amessage to the MMU 3108, 3208 telling it to program the pump 3130, 3230.This message must include the pump ID for the pump 3130, 3230 to beprogrammed and either the patient ID plus order ID, or the universalorder ID, and optionally includes the medication ID (includingmedication name and concentration). The universal order ID or thepatient ID plus order ID information allows the MMU 3108, 3208 to lookup the order information it previously stored in its orders table anddownload the order settings to the pump 3130, 3230 in an eighth processstep 4116. Because the medication ID also was included with theinformation sent to the MMU 3108, 3208 by the POC system 3125, 3225,such information can be included with the order settings downloaded tothe pump 3130, 3230.

In an optional ninth process step 4118, the nurse can adjust or changethe program settings on the pump display 88 or user interface, ifdesired. Because the medication ID was included with the informationsent to the pump 3130, 3230 by MMU 3108, 3208, the pump 3130, 3230 cancheck the pump settings (whether original, adjusted or changed) in atenth process step 4120 and provide an alert to the nurse 3132, 3232 onthe pump display 88 or as part of pump status at other displays withinthe hospital. The nurse is prompted to change the program settings onthe pump 3130, 3230 or, if permissible, override the alert. The steps4118 and 4120 continue in a repetitive loop manner until the pumpsettings meet all the drug library constraints or the associated alertshave been overridden. In an eleventh process step 4122, the nurse 3132,3232 reviews the final pump settings on the pump display 88 and confirmsthem with an appropriate affirmative action, response or acknowledgementon the user interface of the pump 3130, 3230. Upon confirmation, thepump 3130, 3230 prompts the nurse 3132, 3232 with a second screen askingif they are ready to start the infusion. Upon receipt of an affirmativeresponse from the nurse 3132, 3232, the pump 3130, 3230 runs theprogrammed infusion.

As with the other embodiments discussed above, the MMU computer 3108,3208 can continually receive asynchronous (i.e. unsolicited, un-polled)status messages and event logs from the infusion pump 3130, 3230 andstore this information in an associated memory for purposes of at leastdisplaying infusion pump 3130, 3230 status and generating reports. Thisstep has been omitted from FIG. 14 for the sake of brevity. It will alsobe understood by one of ordinary skill in the art based upon the presentdescription that the MMU can poll the pump 3130, 3230 and receivesynchronous communication regarding status and event logs.

FIGS. 1, 2 and 15 illustrate another embodiment of the presentinvention. This embodiment is called a “pump-centric order settingsacquisition” workflow. Like the embodiments of FIGS. 12 and 13, ascanner for machine readable indicia is provided. The scanner can beassociated with the pump 3130, 3230, the MMU 3108, 3208, or the POCsystem 3125, 3225. The scanner can be a stand alone device communicatingin a wired or wireless manner with the pump 3130, 3230, with the POCsystem 3125, 3225 as a POC client 3126, 3226, or even with the MMU 3108,3208 as a client. The scanner can be mounted on or in the pump 3130,3230.

In a first process step 4202, the nurse 3132, 3232 scans his or hercaregiver identification badge 116 to capture the clinician ID. In asecond process step 4204, the nurse 3132, 3232 scans the patientidentification bracelet or badge 112 associated with the patient 3104,3204 to capture the patient ID. In a third process step 4206, the nurse3132, 3232 scans the label 102 on the medication container 3100 tocapture either a medication ID or order ID. In a fourth process step4208, the nurse 3132, 3232 scans the pump or pump channel label or ID 92on the pump 3130, 3230 to capture the pump ID. The first through fourthsteps can be performed in any order that is convenient for the caregiver3132, 3232. In a fifth process step 4210, a program pump message is sentfrom the scanner to the pump 3130, 3230. The message can be sentdirectly to the pump 3130, 3230 from the scanner or it can be sentthrough the MMU 3108, 3208. The message can include the pump ID,clinician ID, patient ID and either the order ID or the medication ID.

In a sixth process step 4212, the pump 3130, 3230 queries the MMU 3108,3208 for the IP address of the POC system 3125, 3225. The MMU 3108, 3208provides the pump 3130, 3230 with the IP address of the POC system 3125,3225. In a seventh process step 4214, the pump 3130, 3230 sends a“getOrderSettings” message to the POC system 3125. The message includesthe order ID or the medication ID and can include further informationsuch as the patient ID. The POC system 3125, 3225 responds by providingor sending the order settings to the pump. This communication preferablyoccurs directly, but can take place indirectly through the MMU 3108,3208 without detracting from the invention. In an eighth process step4216, the pump 3130, 3230 automatically populates the program settingfields on the pump with the order settings it received from the POCsystem 3125, 3225 or the scanner earlier and any other values that canbe calculated from those settings.

In an optional ninth process step 4218, the nurse 3132, 3232 can adjustthe program settings on the pump 3130, 3230, typically on the userinterface and display 88 of the pump. In a tenth process step 4220, thepump checks the program settings against the limits of its drug library,thanks to the medication ID it received from the scanner. Ideally, themedication ID includes medication-specific information, including butnot limited to medication name, concentration (if applicable) andperhaps volume. For this example, the medication ID includes a generic,brand or package level identification of the medication and itsconcentration as well. If the user customizable drug library limits areviolated by the original or adjusted program settings, the pump 3130,3230 generates an alert on its display 88 or other displays within thehospital. The adjust settings, check settings against drug library, andalert steps may be performed repeatedly in a loop until the nurse hascorrected or overridden any alerts. In an eleventh process step 4222,the nurse reviews and confirms the program on the pump 3130, 3230 asdescribed previously and is presented with another screen to actuallystart the programmed infusion.

As with the other embodiments discussed above, the MMU computer 3108,3208 can continually receive asynchronous (i.e. unsolicited, un-polled)status messages and event logs from the infusion pump 3130, 3230 andstore this information in an associated memory for purposes of at leastdisplaying infusion pump 3130, 3230 status and generating reports. Thisstep has been omitted from FIG. 15 for the sake of brevity. It will alsobe understood by one of ordinary skill in the art based upon the presentdescription that the MMU can poll the pump 3130, 3230 and receivesynchronous communication regarding status and event logs.

Any process descriptions or blocks in the figures may be understood asrepresenting modules, segments, or portions of code which include one ormore executable instructions for implementing specific logical functionsor steps in the process, and alternate implementations are includedwithin the scope of the embodiments of the present invention in whichfunctions may be executed out of order from that shown or discussed,including substantially concurrently or in reverse order, depending onthe functionality involved, as would be understood by those havingordinary skill in the art. One skilled in the art will appreciate theorder of the many of the steps in the above embodiments can be changed,as necessary to conform to hospital practices and desired workflow.

One skilled in the art will also appreciate that the present inventioncould be applied to a remote clinic or ambulatory home care environmentand that the patient may serve as his or her own caregiver such thatscanning the patient may determine both the authorized user or clinicianID and the patient ID.

It will be understood that the invention may be embodied in otherspecific forms without departing from the central characteristicsthereof. The present embodiments, therefore, are to be considered in allrespects illustrative and not restrictive, and the invention is not tobe limited to the details given herein.

1. A method for administering a medication to a patient with a medicaldevice, comprising the steps of: receiving at a first computer, incommunication with a second computer, caregiver specific identificationinformation from an identification receiver; receiving at the firstcomputer drug container specific identification information from theidentification receiver, wherein the drug container specificidentification information is located on a container containing themedication; receiving at the first computer medical device specificidentification information from the identification receiver; receivingat the first computer patient specific identification information fromthe identification receiver; receiving from the second computer incommunication with the medical device, an availability state signal forthe medical device; retrieving medical device specific deliveryinformation based on the drug container specific identificationinformation; and, if the availability state signal for the medicaldevice indicates that the medical device is available, then transmittingthe medical device specific delivery information to the medical device,and storing the medical device specific delivery information in amedical device memory for programming the medical device to deliver themedication to the patient.
 2. The method of claim 1, the method furthercomprising the steps of: comparing at least one of the received drugcontainer specific identification information and the patient specificidentification information to stored medication order information withina first memory associated with the first computer; and, transmitting afirst medication delivery initiation signal to the medical device if thereceived drug container specific identification information and/or thepatient specific identification information matches the storedmedication order information within the first memory; wherein the lastmentioned comparing and transmitting steps are only performed if theavailability state signal for the medical device indicates that themedical device is available.
 3. The method of claim 1, wherein themethod further comprises the steps of, if the availability state signalfor the medical device indicates that the medical device is available:generating at the second computer first key information and second keyinformation; transmitting from the second computer the first keyinformation to the first computer; transmitting from the second computerthe second key information to the medical device; transmitting from thefirst computer the first key information to the medical device alongwith the medical device specific delivery information; and, comparing atthe medical device the first key information to the second keyinformation.
 4. The method of claim 3, wherein if a match exists betweenthe first key information and the second key information, thendisplaying the medical device specific delivery information on a displayof the medical device, for review by a caregiver to confirm that atleast the medical device specific delivery information is correct forthe patient, and then operating the medical device according to themedical device specific delivery information.
 5. The method of claim 3,wherein at least one of the first key information and the second keyinformation is an encrypted security token.
 6. The method of claim 1,wherein the medical device comprises an IP address, and wherein themethod further comprises the step of transmitting from second computerto the first computer the IP address of the medical device, if theavailability state signal for the medical device indicates that themedical device is available.
 7. The method of claim 6, wherein the firstmemory associated with the first computer stores the IP address of themedical device within a MAR for the patient for tracking which medicaldevice the medical device specific delivery information is transmitted.8. The method of claim 1, wherein the method further comprises the stepsof, if the availability state signal for the medical device indicatesthat the medical device is available: generating at the second computerfirst key information and second key information, wherein the first keyinformation comprises a time stamp; transmitting from the secondcomputer the first key information to the first computer; transmittingfrom the second computer the second key information to the medicaldevice; and, comparing at the first computer the time stamp to a firstactual time, wherein if the difference between the time stamp and thefirst actual time is less than a predetermined time criteria, thentransmitting from the first computer the first key information to themedical device along with the medical device specific deliveryinformation to the medical device.
 9. The method of claim 8, furthercomprising the steps of: transmitting the time stamp to the medicaldevice; comparing at the medical device the time stamp to an actualtime, wherein if the difference between the time stamp and a secondactual time is less than the predetermined time criteria, thenprogramming the medical device with the medical device specific deliveryinformation.
 10. The method of claim 9, wherein the method furthercomprises the steps of, if the availability state signal for the medicaldevice indicates that the medical device is available: generating at thesecond computer first key information and second key information,wherein the first key information comprises a first time stamp and thesecond key information comprises a second time stamp; transmitting fromthe second computer the first key information to the first computer;transmitting from the second computer the second key information to themedical device; and, comparing at the medical device the first timestamp and the second time stamp to an actual time, wherein if thedifference between the first time stamp and the actual time, and if thedifference between the second time stamp and the actual time, are bothless than a predetermined time criteria, then programming the medicaldevice with the medical device specific delivery information.
 11. Amethod for administering a medication to a patient with a medicaldevice, comprising the steps of: receiving at a first computer, incommunication with a second computer, caregiver specific identificationinformation from an identification receiver; receiving at the firstcomputer drug container specific identification information from theidentification receiver, wherein the drug container specificidentification information is located on a container containing themedication; receiving at the first computer medical device specificidentification information from the identification receiver; receivingat the first computer patient specific identification information fromthe identification receiver; and, receiving from the second computer incommunication with the medical device, an availability state signal forthe medical device, wherein if the availability state signal for themedical device indicates that the medical device is available, then:comparing at least one of the received drug container specificidentification information and the patient specific identificationinformation to stored medication order information stored within a firstmemory associated with the first computer; if the received drugcontainer specific identification information and/or the patientspecific identification information matches the stored medication orderinformation within the first memory associated with the first computer,retrieving at the first computer medical device specific deliveryinformation based on the drug container specific identificationinformation; and transmitting the medical device specific deliveryinformation to the medical device for programming the medical device todeliver the medication to the patient.
 12. A system for administering amedication to a patient, comprising: an identification receiver forreceiving caregiver specific identification information, drug containerspecific identification information located on a container containingthe medication, medical device specific identification information, andpatient specific identification information; a first memory for storingmedication order information comprising medical device specific deliveryinformation; a first computer associated with the first memory, incommunication with the identification receiver, for receiving thecaregiver specific identification information, the drug containerspecific identification, and the medical device specific identificationinformation; wherein the first computer is structured to retrieve themedical device specific delivery information based on the drug containerspecific identification information; a medical device having a medicaldevice memory, the medical device in communication with the firstcomputer, for delivering the medication to the patient; a secondcomputer in communication with the first computer and the medicaldevice, structured to transmit to the first computer an availabilitystate signal for the medical device, wherein the first computer isstructured to retrieve the medical device specific delivery informationbased on the drug container specific identification information, andstructured to transmit the medical device specific delivery informationto the medical device, if the availability state signal for the medicaldevice indicates that the medical device is available, and wherein themedical device is structured to store the medical device specificdelivery information in the medical device memory for programming themedical device to deliver the medication to the patient.
 13. A computerprogram product for operation within a medication management computerfor assisting in administering a medication to a patient using a medicaldevice, comprising: a first code segment for determining an availabilitystate of the medical device; and, a second code segment for transmittingthe availability state signal for the medical device to a point of carecomputer, wherein if the availability state signal for the medicaldevice indicates that the medical device is available, then the point ofcare computer will transmit medical device specific delivery informationto the medical device for programming the medical device to deliver themedication to the patient.